- A TechNote on Unified Communications
- Gary Audin, Delphi, Inc.
The problems with Session Initiation Protocol (SIP) trunking encountered with equipment vendors have in some cases improved and in other ways have become worse since 2011. Every year The SIP School™ performs an international survey, "The SIP Survey 2012," It looks at the status and problems relating to SIP trunking. This year's survey points out that some of the problems with equipment vendors, such as Session Border Controller (SBC) and IP PBX have not been reduced since last year.
You would expect improvement in the situation, with the growth of SIP trunking, coupled with the experience that equipment vendors have attained. Not so. The problems with the SIP trunking providers were covered in a previous TechNote, "How to avoid SIP Trunk Implementation Problems".
The 2012 SIP Survey posed two questions for the respondents dealing with the equipment side of SIP trunking. The survey answers were compared to the 2011 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. SBC failures such as a crash or lock-up have diminished as problems. Required firmware updates to fix problems improved considerably, while SIP registration failures improved modestly. Quality of service (QoS) issues, due to misconfiguration have remained constant when compared to the 2011 survey.
The edge device problems that have gotten worse are:
- Codec issues - This should not be on the rise since those working with this 'specialized' equipment should have a good understanding of codecs. The enterprise staff and value-added resellers (VARs) that are able to work with others involved in an implementation can ensure that codecs are configured correctly and tested thoroughly (the big issue).
- No and one way audio - The rise in numbers reported is quite significant. These issues are strongly highlighting 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 of edge devices.
- Calls to the Public Switched Telephone Network (PSTN) blocked - Since this is a primary reason for adopting SIP trunking, it appears that thorough testing over a period of time was not performed. It may also be the case that the calls were dropped under full traffic loading conditions. Therefore, the edge device should be tested at full traffic load, not assumed to support the traffic load.
One way audio, for example, is most often the result of Network Address Translation (NAT) devices blocking SIP. That means 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 it's private IP address is not routable outside the Local Area Network. The CEO of Ingate, Steve Johnson says that one of the main beneficial functions of the SBC is to resolve that NAT traversal issue and to rewrite the header information so that SIP can reach those devices.
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. The problem centering on SIP trunks that keep "dropping" has much improved, while codec issues are about the same as the 2011 survey results.
The IP PBX problems that have grown are:
- No SIP licenses. That is hard to believe. This begs the question "How much knowledge do enterprises have of the IP PBX they have implemented?" This should be a no brainer. It should not occur at all. Check first with your vendor before deploying SIP trunks, the SIP license may not be included in your procurements.
- SIP registration failures to the ITSP have worsened, not improved. This is probably improper configuration on the part of the IP PBX 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?
- PBX firmware upgrades have become a significant problem. Check with the vendor to determine if there are updates that may affect SIP trunk deployment and operation.
"What's interesting here are the SIP PBX firmware upgrades needed to fix the problem. We've found that certain PBX manufacturers are less willing than others to put out a fix," in the opinion of Sonus Networks Director of Product Management, Mykola Konrad.
Don't Change Configurations by Tweaking for Results
Some enterprise and VAR technicians keep changing the configurations and software settings until the device works properly. This should be avoided as the tweaking can turn off features, 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 (tweaking) starts all over again and the enterprise will continue to encounter outages or poor operation.
Test, Test and Then Test Again
These equipment problems point out that the configuring and testing was done incorrectly or with negligence on the part of the technicians. You have to test to ensure the 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, which is delivered. Full load testing means passing the maximum traffic through the equipment to see if it can deliver the capacity promised.
Remember that there are three participants in this SIP trunking configuration, the IP PBX vendor/VAR, the SBC vendor/VAR and the SIP trunking provider. How much they know about each other is important. Lack of knowledge and experience dealing with the interoperability issues may be the real problem, not the products or services offered.
This article is brought to you in part due to the generous support of:
 |
Gary, nicely done. I can't agree more on the comment about changing the configuration to essentially enable a work around. This not only may turn off features but also can produce an environment of non-standard or unexpected call flows which increase time to resolution.