SIP Trunk Provider Problems PersistSIP Trunk Provider Problems Persist
You would think that with the growth of SIP trunk deployments, the providers would be better at implementation and support. It does not seem so.
May 30, 2013
You would think that with the growth of SIP trunk deployments, the providers would be better at implementation and support. It does not seem so.
Editor's note: This post is by Gary Audin; due to an error in posting, its original byline was incorrectly posted.
You would think that with the growth of SIP trunk deployments, the providers would be better at implementation and support. It does not seem so. What makes problem solving difficult is that five separate parties have an effect on the deployment success: The enterprise; PBX vendor; SBC/firewall vendor; the trunk provider; and the VAR/reseller. The problems may be the fault of any of these parties.
Every year, The SIP School surveys the SIP trunk customer community and issues a free report. This year's version, "The SIP Survey 2013", gathered over 850 worldwide responses, about 350 more than last year, adding accuracy and credibility to the results. About 46% of the responses were from the U.S.
The survey's purpose is to determine what the most common issues are during SIP Trunk deployment and what remedies are available to make these issues occur less frequently or not at all. Understanding these issues will help enterprises focus their efforts on improving the "failing" elements. A second goal is ensuring that staff members understand what to do when things go wrong, so that they are able to fix problems quickly.
The report covers the PBX, edge devices like a Session Border Controller, and the trunk provider. This post will cover the SIP trunk provider problems. A subsequent post will examine the equipment problems related to the PBX and SBC.
The chart below shows the three problem areas and their comparison to the results of the 2012 survey. You will note they are very much the same, a sad state of affairs. There is no appreciable improvement by the providers or equipment vendors. One hopeful note is that a few enterprises had no problems at all--but they are in the minority.
A followup question was, "If you've had problems that were found to be on the SIP Trunk provider side, what were they?" Here are the results:
The 2012 results are shown as a percentage of the 2013 results. Compared to 2012, "Trunk Registration Failures" have improved. "ITSP SIP Server Failures" remained about the same as did "Call Conferencing with External Caller Fails. " Incoming Call Transfer Failure" problems were a little bit worse in the 2013 results. The remaining five areas of concern worsened in the 2013 survey, something that would not be expected since SIP trunk implementations are not new to the providers.
The problem that was worst in the 2012 survey is still the top problem in the 2013 survey, "Trunks Dropping Intermittently." This problem should be addressed during testing/trials.
"One way Audio" is far worse in 2013 than in 2012 and is the second most common problem. This is very likely a provider configuration issue, or it could be attributed to improper configuration of the SBC.
"Codec Mismatch" should not really happen, as configuration settings should ensure a match. This can be fixed on the SBC to conform to the settings of the provider.
"Poor Quality" is an old problem with established fixes. It is difficult to understand how this problem is increasing in frequency. Delay, Jitter, and Packet loss has been discussed for years. Is it due to poor documentation or inadequate configuration practices?
"Trunk Registration Failures" is a little worse in 2013 than 2012 and should not be happening. This could be the fault of improper configuration or a symptom of a provider software problem.
"No Audio" also increased slightly. Again this is probably a provider configuration issue or SBC-generated problem.
The smart IT department should use this report of problems to generate and carry out testing procedures to discover problems before cutover.
Though the above chart focuses on the service provider, they're not necessarily always to blame. Before you condemn the SIP trunk provider, remember there are five possible contributors. If you are depending on a VAR/reseller to manage the implementation, then that party, and not the provider, may be the culprit. Also, if the IT staff starts to attempt the problem resolution, be careful, as their tweaking may produce new problems.
