Avoidable Issues with SIP Trunks

By TMCnet Special Guest
Gary Audin, President of Delphi, Inc.

Implementing a SIP trunk involves five parties: the customer, VAR, PBX (News - Alert) vendor, SBC vendor, and finally the SIP trunk provider. Every year, The SIP School surveys the issues that impede a successful implementation. The 2013 survey should be available in June.

Defining the SIP Implementation Issues

Nine implementation considerations from the SIP Survey are listed below. They can be the responsibility of the SIP provider, IP PBX vendor, SBC vendor or the VAR responsible for implementing the SIP trunk. This list can be used by the enterprise to develop test plans to avoid these issues, and they are listed from the most likely to least likely issue to encounter.

The three most common issues:

• Trunks dropping intermittently is a provider problem. If it happens consistently, check with the provider first before approaching the IP PBX or SBC vendors.
• One-way audio is most likely a configuration issue, poor data entry, or just plain negligence. It could be a misconfiguration in the IP PBX, SBC, or at the trunk provider.
• Poor voice quality created by latency, jitter or packet loss may be the result of not enough trunk bandwidth being allocated. Reevaluate this with the provider.

These are three less likely issues:

• Codec mismatch is a configuration problem that can occur in the IP PBX, SBC or at the provider’s site.
• Trunk registration failures are a provider support issue.
• No audio is probably another configuration issue. It can be in the IP PBX, SBC or at the provider site.

The least common issues are:

• ITSP SIP server failures are the provider’s responsibility to prevent.
• Incoming call transfer failure is another provider responsibility to ensure works properly.
• Call conferencing with an external caller failing is another provider responsibility to resolve.

Preventing the Problems

There will be at least three interested parties to the SIP trunk implementation – IP PBX vendor, SBC vendor, and SIP trunk provider.

Do not try to take the responsibility of coordinating these three without getting them together before and during the SIP trunk implementation. You are not the SIP trunk expert – they are.

Testing the three elements thoroughly is very important. Test the configurations, features to be implemented, and the capacity (number of simultaneous calls) that is required. Make no assumptions. You, the enterprise, will be responsible for the assumptions, not the vendors or providers.

The vendors and providers probably have checklists of what they will perform during the implementation. Obtain these checklists and verify all three have used the checklists to validate the installations. If there are no checklists, create your own checklists by communicating with other enterprises that have implemented SIP trunks. Knowing what has gone wrong at other implementations highlights the issues to be tested. Use the nine issues listed above to anticipate the problems that can occur and test appropriately.

Some technicians keep tweaking the configurations and settings until it does work. This can be dangerous, as the tweaking can turn off features, change security or produce a liability that will show up later. When the tweaking is performed, ensure that adequate and correct documentation is produced so there is an audit trail available if problems occur in the future. If not, the tweaking starts all over again and the enterprise will continue to encounter outages or poor operation. For example, Transport Layer Security (TLS) or Secure Real Time Protocol (SRTP) may be turned off and thereby eliminate the security features. Codec changes to more or fewer ports on the SBC could be configured improperly.

Edited by Alisen Downey