Resolving Pesky Reoccurring SIP Trunk Problems
SIP trunking does not yet appear to be a commodity implementation. As the results of The SIP School’s 2018 SIP and Cloud survey show, problems persist, year over year, on both the provider and equipment sides. You can read more on those problems in my last two blogs -- here and here -- but now, let’s take a closer look at problem prevention and resolution for SIP trunk implementations.
There will be at least three external interested parties to the SIP trunk implementation -- IP PBX/UC vendor, session border controller (SBC) vendor, and SIP trunk provider. In addition, there will probably be a value-added reseller (VAR) as part of the implementation project. As an enterprise, your staff is also a participant. Do not take the responsibility of coordinating these participants without getting them together before and during the SIP trunk implementation. You are not the SIP trunk expert. They are.
When looking for ways to avoid SIP implementation problems, focusing on configuration control and management is a great place to start. Most of the time there are not problems with the technology; it is mature. Looking at The SIP School’s survey, most of the problems can be avoided if you reduce configuration errors and negligence.
When it comes to avoiding codec issues, look for a SIP trunk provider that has the capability to dynamically select a codec that the PBX side prefers (G.711, G.729, G.722, H.264).
You should test the configuration, features to be implemented, and the capacity (number of simultaneous calls) that is required. Make no assumptions. Functional tests are of value, but successful functional tests do not indicate that there will be success once there is a full traffic load.
SIP vendors and providers have checklists of what they will perform during the implementation process. Obtain these checklists and verify that they have used the checklists to validate the installations. If there are no checklists, create your own by communicating with other enterprises that have implemented SIP trunks. And use the 2018 SIP Survey to anticipate the issues that can occur.
Some technicians keep tweaking the configuration and settings until the SIP connections work. This can be a dangerous practice, as the tweaking can turn off features, change security, or produce a liability that will show up later.
For example, Transport Layer Security (TLS) or Secure Real Time Protocol (SRTP) may be inadvertently turned off, thereby eliminating the security features. Codec changes or more/fewer ports on the SBC could be configured improperly.
When this kind of tweaking is performed, ensure that adequate and correct documentation is produced so there is an audit trail available. That way, if problems occur in the future, you’ll know where to look. If everything is not documented, the tweaking starts all over again and the enterprise will continue to encounter outages or poor operation.
One of the reasons failures occur is that the configured timeouts are too short. Before you declare a failure, verify the timeouts and ensure that they are not too short. When registration is not stable, first verify that the Internet connection is operating properly. Check the refresh time in the trunk’s overflow and adjust the failure rate settings (“Keep Alive Time”) to about 20 seconds. If registration does not work at all, verify that the correct password and authentication are in use.
When trunks continue to drop after some successful operation, check the provider’s IP connection. Check the configuration settings on the SBC. Set up a signaling trace to verify that the SIP signaling is operating properly. If a firewall is connected to the SIP trunk, verify that the firewall will pass and not filter SIP signaling. It could be blocking the SIP signaling.
Audio problems are common. Not all carriers offer G.711 end-to-end. It may be G.711 at the edges but compressed to G.729 before entering the network, blocking FAX, PC modems, music on hold, and telemetry connections. Test the codec settings to ensure they match and for one-way audio before initializing the SIP trunk connection. Audio quality problems are more likely associated with there not being QoS in use, or there not being enough bandwidth allocated for the trunk.
The SBC and/or the IP PBX should have the ability to detect ITSP/SIP server failures. The enterprise cannot fix this problem, but rapid notification to the providers by the enterprise will reduce the outage time. If this kind of problem persists, however, consider terminating the SIP trunk agreement.
Do You Have Enough Bandwidth?
Bandwidth can seriously affect the voice quality and the number of simultaneous sessions/calls. Over-design wastes money and requires more bandwidth. Under-design blocks calls, frustrates customers, and can affect call quality. More recommendations include:
- Use G.711 end-to-end for call centers and provision up to 20% more channels and bandwidth than calculated
- Do not implement silence suppression unless there are more than 24 channels and fax transmissions as well as music on hold are turned off
- Test the SIP trunk operation with the SBC connected, and test at full load
How About Licenses?
A SIP license per SIP trunk path/session/call is required for the IP PBX and the SBC. If you don’t have enough licenses, you will run into blocked calls.
Some IP PBXs and SBCs come with five to 50 licenses, and licenses can often be added in increments of four, five, 10, etc., so there is no uniformity among providers. SIP licenses are an additional cost on top of the SIP trunk provider charges. IP PBX and SBC licenses are forever. Some IP PBXs and SBCs have limited licensing sizes, meaning that when you buy a small IP PBX it usually has an upper limit to the number SIP sessions it can support There will be no refunds for over buying, so it’s important to determine the peak number of sessions and then acquire the appropriate number of licenses.