It all started with a request to install a IP Office system… Doesn’t it always?
A client out in the western Illinois area bought an IP500v2, IP phones, a T1 card and 16 extra channels at a large online store. Unfortunately or actually expectedly this ended poorly for our client… Here’s what happened:
Whoever was working at this store was, shall we say, short on the facts, which inevitably caused trouble for our client. For one example, the salesman explained that the T1/PRI that our client had just purchased automatically connects to the Internet; this is blatantly incorrect. Negligence at its finest!
Of course many service providers deliver T1/PRI service through a “data” connection, which can be confusing if not fully explained to clients. This is especially true for when the client might not have the knowledge of networks and circuits and just wants a dial tone when they pick up the handset.
If they could do it all themselves, they wouldn’t need our help!
We were thankfully able to bring this to the client’s attention in advance. We were able to discover the error through paying a keen attention to what the client had and through interrogating the client thoroughly. We were able to question the existence of the PRI circuit early on, and solve the problem.
How did we do that? Dedication!
With some research we discovered that no circuit was ever ordered, but their data provider had a 10m fiber link to them. A PRI circuit would take the typical 4-6 weeks to deliver, and of course the price for a stand-alone T1 was sky high. The client had to weigh some options, but after discussing a few solutions with the client, we helped them to decide on ordering SIP trunks from their Internet provider.
Unfortunately for us, Avaya did not have any Application Notes written about this provider and their SIP. So we took that extra step and requested that data from the provider, details on their SIP provisioning and were assured they had clients with SIP connectivity on Avaya IP Office systems.
Then comes the day of reckoning!
On install day, we finally set up the system, IP phones, and add the SIP trunk licenses. To our unpleasant surprise, we discover that the provider had sent us 3 different settings for the SIP connection, and was impatiently waiting to “port” all their numbers. After putting a quick stop to that debacle, we then had to decipher their “provisioning” information… which, of course, was nothing close to the conventions that are part of the IP Office SIP trunk setup.
After a few hours of diagnosing the connection to their SIP registrar server, we determined that the client’s firewall (which the provider managed), was incompatible and had to be replaced. Once the system could talk to the SIP registrar, the SIP trunks came up as idle. After testing them a few times, we could only get inbound calls to work. At first.
At first, the client didn’t want to set up a test number, which was a struggle for us. After all, how are you expected to test calls without that basic requirement? Nonetheless, the problem we faced was getting outbound calling to work.
After more testing and changing settings, we could not get past a very frustrating SIP: 480 ‘no routes found’ response message… which is not part of the standard SIP messages. (SIP: 480 ‘temporarily unavailable’ is more common, thus what we expected to see.) We were told to bring technical support for the problem, which should’ve been the end of it. However, as I was sending out the invite and received the trying messages as expected, the provider rejected the call.
Could it be more frustrating? Of course! But that’s the nature of this line of work. If it’s easy, we’re not called in. So we chugged on ahead, determined as always to find a solution!
After reviewing several application notes on the SIP connection testing with Avaya and other SIP vendors, we found all the standard settings were done in accordance. The problem lied in the service provider.
The provider, once they could trace the call attempt, had me setup a separate registrar. With that, the SIP:480 no “routes found” message changed to what we expected it to be: SIP:480 “temporarily unavailable.”
Progress!
At the last test, they required the IP address in the from field which have all shown as “name.com” for all the SIP provider connections introduced in the application notes.
Finally a call out worked! Anyone in this field knows the joy and relief of a job completed.
REVIEW
In the end, we looked back and reviewed the entire process. From the beginning, it seems that there were several issues preventing the SIP trunks from operating throughout this effort:
1. Bad router
2. Lack of good information from multiple sources
3. Changes to the registrar (mostly a secondary one) setting the system’s IP, rather than the provider’s “name.com” (which had been identified in all the sip trunk application notes.)
We completed the installation without further trouble. The SIP trunks are working very well and have good call quality.
All’s well that ends well!
*** Update late 2012. The provider changed something on their end (after a year of SIP running smooth). Customer was down. The provider could NOT figure out how to correct and gave the customer PRI for the same price as their SIP.
*** Update late 2012. The provider changed something on their end (after a year of SIP running smooth). Customer was down. The provider could NOT figure out how to correct and gave the customer PRI for the same price as their SIP.
