Different Year, Same Old SIP Trunk Provider Problems
One-way audio, dropped trunks, and poor call quality persist in plaguing SIP trunking implementations, a recent SIP survey shows.
You would think by now that implementing SIP trunks would be a no-brainer, nearly plug and play. Not so, as we learned from a recent No Jitter post "SIP Surprises."
In that post, Andrew Prokop, director of vertical industries at Arrow Systems Integration, shares his key takeaways from The SIP School's recently published SIP Survey 2015. We're alike in thinking that the survey results on SIP problems are noteworthy.
For this year's survey, The SIP School fielded responses from nearly 1,100 participants, the majority from enterprise organizations using SIP trunks. And what their responses indicate is that the SIP trunk providers remain the single biggest source of implementation problems -- although issues do, of course, continue to crop up on the equipment side, too.
Problems Point to SIP Trunk Providers
In previous SIP School surveys, the percentage of problems attributed to SIP trunk providers, session border controller (SBC)/edge equipment vendors, and the IP PBX vendors were about equal. This year's survey, however, found the equipment vendors have done a better job delivering successful SIP trunking implementations. Respondents attributed more than one-third of the problems to SIP trunk providers. At 16% and 21%, respectively, the IP PBX and SBC vendors fared better than in previous surveys.
Of course, some SIP implementations do go as planned. About one-sixth of those organizations responding had no problems, a new selection option in this year's survey. That some respondents had no problems is a heartening development. However, the "no problem" response should be much higher since SIP trunk connections are becoming a commodity.
SIP trunk providers, equipment vendors, and enterprises using SIP trunks might learn from this list of reasons cited for achieving a problem-free experience. Most are just good practices, so I have to wonder why they're missing in the problem-filled implementations:
- Good connectivity to the SIP network
- Correct hardware configurations plus good systems (IP PBX), effective planning, useful support
- Good design, including failover support
- Certified configurations -- configuration issues are frequently cited by those who have experienced problem implementations
- Interoperability matrix, for mapping out all the component interfaces
- Smart people assigned to the implementation
- Excellent technicians
- Good support plus SIP knowledge
- Thorough and well-planned testing
- Good product documentation
That some SIP trunk providers and equipment vendors can deliver without problems demonstrates that competitors are not focusing on the implementations or don't have the requisite knowledge and experience.
The Same Problems Persist
In his post, Andrew shared a graphic showing all the different things that can go wrong on the provider side. I've included it below, too, since there is a significant chance you will have one or more of these SIP trunk implementation problems. Anticipate them. Use the graphic to create a checklist to verify the provider implementation.
As you can see, the worst problems are one-way audio, dropped trunks, and poor call quality. These are persistent issues -- read my 2014 No Jitter post, "Provider Issues Still Dog SIP Trunks", and you will learn that these three problems were the most common last year and in 2013, too. Makes you wonder. Will the involved parties, including the enterprises and VARs, ever learn? It is frustrating to report year after year about the same complaints.
It appears that many of the problems are incorrect configuration settings. IP telephony providers are supposed to provide settings necessary for successful operation. The enterprise and/or the VAR are not doing their jobs ensuring the settings are correct. These settings include the IP address, Domain Name System address, port numbers, Real-Time Transport Protocol packet rate, codec , and the Network Address Translation configuration.
One consideration the survey did not cover is the traffic capacity of the SIP trunk. You order the trunk by the number of simultaneous sessions. Try to load up the SIP trunk with the maximum traffic to ensure it operates successfully under full load. This is the final test. Even if all the individual tests work, you may have an unexpected problem under full load. The smart IT department should use this survey of problems to generate and carry out testing procedures to discover the problems before cutover.
As another No Jitter blogger, Alan Percy, commented in the survey response: "It seems that there is a need for a test suite that should be built into every SBC/PBX that does an initial test of the SIP trunk during the activation process. That would avoid exposing the end-customer to many of these issues."
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 may be the culprit and not the provider. Also, if the IT staff starts to attempt the problem resolution, be careful its configuration tweaking may produce new problems.
In my next blog, I will discuss the improvements and remaining problems with SIP trunk equipment vendors. And join me at Enterprise Connect 2016, coming March 7 to 10 in Orlando, Fla., where I'll be moderating the session, "SIP Trunking Triumphs and Torments." (You can even register now using the code NOJITTER and receive $200 off the current conference price.)