October 8, 2012

How to avoid SIP Trunk Implementation Problems

The problems with Session Initiation Protocol (SIP) trunking have gotten worse, instead of improving for SIP trunk providers. Every year The SIP School™ conducts an international survey, "The SIP Survey 2012". That survey looks at the status and problems relating to SIP trunking. We will focus on how you can avoid and even sometimes solve those problems.

This year's survey points out that the problems with the SIP trunk providers have increased since the 2011 survey, while the problems with edge devices like the Session Border Controller (SBC) and with the IP PBX have remained about the same.

If you've had problems, where have the issues been?
Source: The SIP Survey 2012

It is surprising that the SIP trunk providers have been degrading rather than improving their implementations. There are four major problems that stand out as increasing in occurrence, while other issues have changed little or even reduced in frequency.

If you've had problems that were found to be on the SIP trunk provider side, what were they?
Source: The SIP Survey 2012

All of the issues in the chart above have been around since the beginning of SIP trunk implementation. It is disappointing that the industry still has not reduced the problem frequency. These are basic implementation issues that should be eliminated during the initialization of the SIP trunks.

It makes you wonder, are the implementation teams overworked, undertrained or both? Or could it be that the providers have not made these problems high priority on their list of improvements? It would seem that the cost to the provider for resolving these problems could be avoided by further investment in the implementation team along with the necessary testing when SIP trunks are installed.

The Problems

The most frustrating problem is trunks dropping connections intermittently. This means the call connection just disappears without any user-generated event causing the problem. The user has no idea what has happened. It may a while before the dropped connection is even detected by the user if the conversation is primarily a one-way monologue.

Registration failures are usually account issues. Poor voice quality can be caused by network problems such as jitter, packet loss, and network latency/delay. Internet Telephony Service Provider (ITSP)/SIP server failures should be rare occurrences.

Resolving the Problems

When trunks continue to drop after some successful operation, check the provider's IP connection. Check the configuration settings on the SBC. Set up a signaling trace to verify that the SIP signaling is operating properly.

When registration is not stable, first verify that the Internet connection is operating properly. Check the refresh time in the trunk's overflow and failure rate settings "Keep Alive Time" to about 20 seconds. If registration does not work at all, verify that the correct password and authentication are in use. If a firewall is in the connection to the SIP trunk, verify that the firewall will pass and not filter SIP signaling. It could be blocking the signaling.

Even though codec mismatch and one-way audio problems are less prevalent, do not assume that they cannot occur. Test these before initializing the SIP trunk connection. Audio problems are more likely associated with no quality of service (QoS) in use or not enough bandwidth has been allocated for the trunk.

The SBC and/or the IP PBX should have the ability to detect ITSP/SIP server failures. The enterprise cannot fix this problem, but rapid notification to the providers by the enterprise will reduce the outage time. If this persists, then consider terminating the SIP trunk agreement. Server failures should not be a recurring problem.

Preventing the Problems

There will be at least three interested parties to the SIP trunk implementation, IP PBX/UC vendor, SBC vendor and SIP trunk provider.
Do not try to take the responsibility of coordinating these three without getting them together before and during the SIP trunk implementation. You are not the SIP trunk expert. They are.

Testing the three elements thoroughly is very important. Test the configuration, features to be implemented, and the capacity (number of simultaneous calls) that is required. Make no assumptions. You the enterprise will be responsible for the assumptions, not the vendors or providers.

The vendors and providers probably have checklists of what they will perform during the implementation. Obtain these checklists and verify they have used the checklist to validate the installations. If there are no checklists, create your own checklists by communicating with other enterprises that have implemented SIP trunks. Use The SIP Survey 2012 to anticipate the issues that can occur. Knowing what has gone wrong at other implementations highlights the issues to be tested.

Some technicians keep tweaking the configuration and settings until it does work. This can be dangerous as the tweaking can turn off features, change security or produce a liability that will show up later. When the tweaking is performed, ensure that adequate and correct documentation of the changes is produced so there is an audit trail available if problems occur in the future. If not, the tweaking starts all over again and the enterprise will continue to encounter outages or poor operation. For example, Transport Layer Security (TLS) or Secure Real Time Protocol (SRTP) may be turned off and thereby eliminating the security features. Codec changes or more or fewer ports on the SBC could be configured improperly.

When the SIP trunk does not work properly, remember that the problems could also be the result of the IP PBX or SBC improperly configured. This makes it more difficult to pinpoint the culprit. If the corrections performed by the SIP trunk provider do not work, enlist the aid of the SBC vendor and IP PBX vendors before you declare the SIP provider as incompetent.

This article is brought to you in part due to the generous support of:


What do you think are the problems with SIP providers’ implementation success?

Most of the problems appear to be configuration mistakes. I think that the provider’s implementers do not have enough training, experience and adequate documentation especially for troubleshooting.

Gary's points are probably true, to varying degrees, in all projects. However, another cause of problems I have seen in several projects, though they were not SIP projects,is that project managers and other stakeholders, will sometimes disregard the advice of the experts that they have working for them. Their position allows them to use their own inferior knowledge based decision to overrule the correct decision. This can lead to many problems, since they have authorized an incorrect course of action.

some SBC's supplier didn't adviced the service provider clearly. some service provider didn't exchange their proper network informations clearly. most of them used H.323 gate keeper then the rtp didn't reached to the media gateway due to the firewall blockage. this is most of the problems that i faced with my voip partners. i prefer to use SIP instead of H.323.

Is there any data that might rate the performance of the various carriers?

It is not training it is the stove piped engineer problem.
Providers are never going to be trained on customer equipment. CPE suppliers are never going to know the nuances of the network.
Site equipment suppliers all know how to configure unknown numbering, how to manip ip addresses in headers. They also can set up in several different ways depending on what the SBC is expecting.
Providers know what headers the network is sensitive to.
SBC folks sit in the middle and know how to manipulate any header, but generally need guidance from both sides as to what is expected.

What is needed is someone who can view the integration end to end and make recommendations that sound like these:

CPE unkown numbering is providing a valid number in the P-assert, but the IP address in the assert is not the outside address of the SBC--that is the only address the net provider will accept.

I see a "+1" in the toll free URI, we are expecting the provider to knock the DNIS down to 10 digits.

The From header does not contain a number known to the network and there is no overriding p-assert.

The URI host is Somebody.com on the inbound call and that is not a known domain on the CPE.

I have a theory that there are two forces at work causing the slip in success:

1. A greater number of partners/end-users are giving SIP Trunking a try for the first time, meaning this is their first implementation and thus some basic mistakes result.

2. Greater use of Over-the-top service providers - which I feel is good, but potentially creates traffic or reliability issues that many new users are not prepared to address (see #1 above)

Anyhow, keep up the good work!

We have implemented over 5 IP PBX. We spent over 4 months just testing in various scenarios before carrying out our 1st install. Time well spent in my opinion as various people who have sourced a similar service from another vendor, have raised concerns matching your survey. SIP provider we use has a very mature product, proactively monitoring various aspects of IP Telephony.
We've a very good template to speed up deployment.

Get E-News and Notices via Email




I accept Webtorials' Terms and Conditions.

Featured Sponsor Microsites

Recent Tweets



Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Please encourage colleagues to download their own copy after registering at https://www.webtorials.com/Sonus_logo.jpgreg/.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2015, Distributed Networking Associates, Inc.