SIP Trunking Equipment Problems Also PersistSIP Trunking Equipment Problems Also Persist

Issues relating to the IP-PBX or SBC may also hamper SIP Trunk performance.

Like the problems with SIP trunking service providers, which we discussed last week, problems with the equipment used in SIP Trunking implementations (such as Session Border Controllers and IP-PBXs) have also persisted from last year to this year, according to The SIP School's annual survey ("The SIP Survey 2013).

The 2013 SIP Survey posed two questions for the respondents dealing with the equipment side of SIP trunking. This year's survey answers were compared to the 2012 survey results:

Edge Device Problems
First survey question: If your problems were with your SBC / Edge devices, what were they?

Let's first look at what has improved. The "No Audio" and "Calls to the PSTN Blocked" have diminished as problems. In six other categories, the problems have increased, not decreased from the 2012 survey levels.

The biggest problem, "One Way Audio," remains the primary headache with the SBC. This was the worst problem in 2012 and remains the worst problem in 2013. The rise in this number is significant. This issue strongly highlights the importance of testing the components together before deploying and initializing the SIP trunking service. The results of the testing could influence the purchasing decisions on edge devices.

"One Way Audio" is most often the result of "NAT breaking SIP" which means that since SIP operates at the Application Layer and the NAT is created at the transport layer of the network, media often cannot reach the SIP device being used in the network because its private IP address is not routable outside the Local Area Network. One of the beneficial functions of the SBC--when it's working properly--is to resolve that NAT traversal issue and to rewrite the header information so that SIP can reach those devices.

"Codec Issues" is the next most common problem. This should not be on the rise, as those working with this 'specialized' equipment should have a good understanding of codecs. The enterprise staff and VARs that are able to work with others involved in an implementation should ensure that codecs are configured correctly and tested thoroughly.

"SIP Registration Failures" is next on the list, which is most likely a configuration problem. "QoS Issues" is another problem probably due to mis-configuration.

Required "Firmware Updates" to fix problems worsened considerably. This appears to be a problem on the part of the VAR or IT department. It is also possible that the SBC vendor is not being diligent in their downloads.

"SBC Failures" such as a crash or lock-up have increased but remain a minor problem. This problem is solvable during the testing phase and should not have increased at all.

IP-PBX Problems
Second survey question: If the problems were found to be with your SIP/ VoIP based PBX, what were they?

There are five areas of concern with the IP-PBX vendors' SIP trunks support. Most have improved or remained the same.

"PBX Firmware Upgrades" have become less of a problem, but still remain the biggest problem. Check with the vendor to determine if there are updates that may affect SIP trunk deployment and operation.

"Codec Issues" have increased noticeably since the 2012 survey and are now the second-most-common problem behind firmware upgrades. This is most likely a mis-match configuration problem. Check the settings carefully.

"SIP Registration Failures" to the ITSP have remained the same as the 2012 survey, but now rank behind Codec Issues. Registration failures are probably due to improper configuration by the enterprise staff or more likely the VAR. In either case, I question the enterprise and VAR training as well as the vendor documentation. Is it just poor typing skills and/or unverified data entry?

"SIP Trunks Keep Dropping" has declined slightly as a problem.

"No SIP Licenses" is hard to believe. This begs the question, "How much knowledge do enterprises have of the IP-PBX they have implemented?" Check first with your vendor before deploying SIP trunks. The SIP license may not be included in your procurements. This should be a no-brainer. It should not occur at all, and it's good to see that it is apparently declining.

Test, Test and Then Test Again
These equipment problems demonstrate that the configuring and testing was done incorrectly on the part of the technicians. You have to test to ensure that features and functions are working. You should also test the features and functions under a full traffic load. That is when unknown problems will surface. Full-load testing will help to determine the actual performance, not theoretical performance. Full-load testing means passing the maximum traffic through the equipment to see if it can deliver the capacity promised.

Don't Change Configurations by Tweaking for Results
Some enterprise and VAR technicians keep changing the configuration and software settings until the device works properly. This should be avoided, as the tweaking can turn off features, change security settings by discontinuing a security feature or blocking calls, or produce a liability that will cause problems in the future. When changes are made to solve a problem, ensure that the documentation of the changes is produced so there is a useful record available if new issues emerge in the future. If not, the change procedure starts all over again and the enterprise will continue to encounter outages or poor operation.

Remember that there are five participants in this SIP trunking configuration: the IP-PBX vendor, the SBC vendor, VAR, the SIP trunking provider and the enterprise staff. How much they know about the other is important. Lack of knowledge and experience dealing with the interoperability issues-- not the products or services offered--may be the real problem,.