Lessons Learned on a SIP ImplementationLessons Learned on a SIP Implementation

To issues as you cut over to a SIP trunking installation, be sure to coordinate among the IP/PBX vendor, the SBC vendor, and SIP trunking provider.

We had a client who installed SIP trunking with AT&T, which calls their product IP Flex. Some of the problems that we experienced were:

* NAT (Network Address Translation) Traversal problems
* Codec mismatches
* 911 calls where the address did not show up
* One way audio issues
* Carrier SIP Server failures
* Calls dropping on SIP trunk

In this article, we want to share our "lessons learned," in the hopes you do not experience what we did, and to shed light on your future implementation of SIP.

I feel that AT&T's people did not understand the product prior to selling it, nor did they understand all the integration issues that need to go along with it. (This install happened in October 2012). In this case, we were porting 2,500 DID numbers away from AT&T PRIs and over to AT&T SIP Trunking.

The problems encountered on this phase were the fact that the PRIs were under "legacy" AT&T (i.e., the former Ameritech regional Bell operator) and were being ported over to "new AT&T" (under successor SBC/AT&T). AT&T's systems kept rejecting the ported numbers, citing "non-concurrence"--basically, meaning the 2 systems could not talk to one another or integrate with each other. It took them 3 tries and 45 days to get this straightened out to where the systems would talk to one another and successfully accept all numbers to be ported over.

The issue with the 911 eventually worked out, but it didn't on the night of cutover. The reason was the fact that AT&T took 7-9 business days for the 2,500 DID port order to be accepted into the system and thus passed through the system. Once the order process completed after the 9th day or so, then the 911 address could be passed over to the PSAP. In the meantime, we had to have our SIP Proxy vendor make a temporary fix, and after 9 days we could change the temporary fix back to the AT&T permanent solution.

The carrier SIP issues were related to AT&T using a Cisco 3945 Router on the customer premise. This router was configured with 256 routes or concurrent voice sessions--which turned out to be insufficient for our needs. Once AT&T increased the routes to 1,200, the calls started flowing again and the audio issues went away.

We also had to continually use WireShark to determine if the problems were with the SIP proxy server or AT&T's Central Office. This was the only way to work with AT&T to prove to them some of our issues.

The issue of SIP dropping calls came to our attention based on complaints from users that the call connection just disappeared without any user-generated event causing the problem. Most of the time the user had no idea what had happened. We had to have AT&T check their connection, and our SIP Proxy vendor had to check their configuration settings on the SBC. This is where we set up the signaling trace over WireShark to verify that the SIP signaling was operating properly.

On the Codec mismatches, the Transport Layer Security (TLS) was turned off, thereby eliminating the security features. Once the TLS was enabled, the Codec mismatches went away. The Codec changes and the SBC were not configured properly for the IP/PBX.

To avoid these and similar types of issues as you cut over to a SIP trunking installation, we advise you to coordinate among the IP-PBX vendor, the SBC vendor, and SIP trunking provider. All should meet via conference call prior to implementation and during implementation. All vendors should be on the conference bridge during the SIP cutover as well. We also recommend that you come up with a checklist and testing scenario of business requirements that occur on a day-to-day basis at your enterprise. These tests and checklists are crucial to the success of a SIP implementation.

Barb Grothe is CEO and Principal Consultant of Telecom Resources, Inc. an independent IT consulting firm based in Indianapolis, IN. Barb is a Member of the Society of Telecommunications Consultants. She can be reached at [email protected] or www.tel-res.com.