No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

SIP Trunk Equipment Still Needs Work

The implementation of SIP trunks is a fairly complex process that involves the participation of at least five parties: the SIP trunk provider, PBX vendor, SBC vendor, VAR, and the end user enterprise. Any one of these can make or break your SIP trunking implementation success. Because SIP trunking is becoming a commodity installation, there really should be minimal problems; unfortunately this is not the case. You can expect problems to arise in four out of five SIP trunk implementations.

In my previous blog "SIP Trunk Providers Still Learning," I investigated the problems associated with the SIP trunking provider. In this blog, I'll focus on the two equipment vendors involved in the implementation process, the PBX and the SBC/Edge device vendors.

The SIP School produces an annual SIP survey, and the recently released 2016 results make it the sixth year running. With 929 professionals responding to the survey, the results demonstrate that little has improved since 2015. The equipment vendors have fewer problems than service providers, however, most of the same equipment problems continuously persist year after year.

I have to wonder whether any of the equipment vendors read the survey and modify their products in response to issues discovered in the survey. It appears that the issues reported are not necessarily learned from and resolved by those involved in supporting SIP trunk implementations.

Commonly, a session border controller (SBC) is placed between the enterprise PBX and the SIP trunk provider. However, the SBC function could be included as a cloud service, or it might be integrated into the PBX, or a firewall may be used.

The chart below from The SIP School survey points out that one-way audio still dominates the problems with the SBC with 49.35% reporting the issue in 2016, down from 59.26% in 2015, a good reduction. Fixing one-way audio is one of the common justifications people present for deploying an SBC. Misconfiguration is the most likely cause of problems with the SBC.

The next most common problem is CODEC issues, reported by 36.35% in 2016, up from 31.48% in 2015. This is a matter of paying attention to the configuration documentation. It can be due to lack of planning and incorrectly entered configuration settings. But these problems should not happen. SIP registration failures are up in 2016 at 37.66% from 31.48% in 2015, and these issues are also probably due to misconfiguration. Be patient. Take time to properly configure the SBC to reduce the time needed for troubleshooting and fixing other issues.

You may want to use a cloud service as a virtual device. It will be easier to manage by the Internet telephony service provider (ITSP). It is easier to configure thousands of virtual SBCs in their cloud than to ensure that the SBCs at the client sites receive the correctly installed required changes.

There is more discouraging news in the survey: SBC failures increased by 5%; QoS issues increased by 5%; blocked calls increased by 6%; and firmware updates decreased by 7%.

The PBX vendors continue to contribute the fewest problems for SIP implementations, as shown in the chart below. But they still have problems. Manual configuration errors still tops the list of problems. However, configuration errors have dropped from 70.73% in 2015 to 57.14% in 2016, a considerable improvement.

Unfortunately PBX firmware upgrades needed to fix issues jumped from 17.07% in 2015 to 37.05% in 2016, indicating that the problem more than doubled over the last year. Software changes rapidly, which may result in the reduction of firmware testing time or no testing time at all. The other three issues are a mixed bag. The problem of SIP trunks keep dropping is up roughly 4% from 2015, however SIP registration failures is down 5% over last year, and the problem of not having SIP licenses is up 1.5%, which is very hard to understand. Do the customers know what they own?

Enterprise IT staff are not experts on SIP trunking. You need to talk to the all parties involved in the implementation. Try to gain access to case studies from providers and vendors. Talk to the equipment vendors and providers about their installation experiences and best practices. Ask for some sites they can recommend visiting and understand the problems that occurred with those vendors and the providers.

Typically, most of the trouble arises from issues with interoperability among all the vendors and providers, as well as their conformance to standards. Look for recommendations like SIPConnect from the SIP Forum. The vendors and providers do not know your situation in detail. Document your business requests and evaluate if they can be covered by those offering products and services.

One of the most important points to focus on is a Service-Level Agreement (SLA) for small sites and remote locations. You may find that international locations are not included in the SLAs, or the SLAs are watered down. Understand what is and is not covered by the ITSP. There are always demarcation points between vendors and providers.

Security in today's environment is on top of most IT network lists. Find out what the ITSP is doing to provide secure access to the SIP trunks and access in the reverse direction to the SBC. SIP trunks will be connected to mobile devices. You have other systems like CRM, marketing, and sales. How does the SIP trunk equipment integrate with these systems? If the ITSP provides a connection to the on-premises system, what will happen if you decide to migrate to the cloud in the future? These are all things you need to know to minimize problems that surface during a SIP trunking implementation.

For a deeper look, last year's blog, "Why SIP Problems Persist--and What to Do About Them" covers the 2015 edition of The SIP School survey.