- A TechNote on Unified Communications
- Gary Audin, Delphi, Inc.
The problems with Session Initiation Protocol (SIP) trunking have gotten worse, instead of improving for SIP trunk providers. Every year The SIP School™ conducts an international survey, "The SIP Survey 2012". That survey looks at the status and problems relating to SIP trunking. We will focus on how you can avoid and even sometimes solve those problems.
This year's survey points out that the problems with the SIP trunk providers have increased since the 2011 survey, while the problems with edge devices like the Session Border Controller (SBC) and with the IP PBX have remained about the same.
It is surprising that the SIP trunk providers have been degrading rather than improving their implementations. There are four major problems that stand out as increasing in occurrence, while other issues have changed little or even reduced in frequency.
All of the issues in the chart above have been around since the beginning of SIP trunk implementation. It is disappointing that the industry still has not reduced the problem frequency. These are basic implementation issues that should be eliminated during the initialization of the SIP trunks.
It makes you wonder, are the implementation teams overworked, undertrained or both? Or could it be that the providers have not made these problems high priority on their list of improvements? It would seem that the cost to the provider for resolving these problems could be avoided by further investment in the implementation team along with the necessary testing when SIP trunks are installed.
The Problems
The most frustrating problem is trunks dropping connections intermittently. This means the call connection just disappears without any user-generated event causing the problem. The user has no idea what has happened. It may a while before the dropped connection is even detected by the user if the conversation is primarily a one-way monologue.
Registration failures are usually account issues. Poor voice quality can be caused by network problems such as jitter, packet loss, and network latency/delay. Internet Telephony Service Provider (ITSP)/SIP server failures should be rare occurrences.
Resolving the Problems
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.
When registration is not stable, first verify that the Internet connection is operating properly. Check the refresh time in the trunk's overflow and 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. If a firewall is in the connection to the SIP trunk, verify that the firewall will pass and not filter SIP signaling. It could be blocking the signaling.
Even though codec mismatch and one-way audio problems are less prevalent, do not assume that they cannot occur. Test these before initializing the SIP trunk connection. Audio problems are more likely associated with no quality of service (QoS) in use or not enough bandwidth has been 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 persists, then consider terminating the SIP trunk agreement. Server failures should not be a recurring problem.
Preventing the Problems
There will be at least three interested parties to the SIP trunk implementation, IP PBX/UC 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 configuration, 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 they have used the checklist to validate the installations. If there are no checklists, create your own checklists by communicating with other enterprises that have implemented SIP trunks. Use The SIP Survey 2012 to anticipate the issues that can occur. Knowing what has gone wrong at other implementations highlights the issues to be tested.
Some technicians keep tweaking the configuration 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 of the changes 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 eliminating the security features. Codec changes or more or fewer ports on the SBC could be configured improperly.
When the SIP trunk does not work properly, remember that the problems could also be the result of the IP PBX or SBC improperly configured. This makes it more difficult to pinpoint the culprit. If the corrections performed by the SIP trunk provider do not work, enlist the aid of the SBC vendor and IP PBX vendors before you declare the SIP provider as incompetent.
This article is brought to you in part due to the generous support of:
This year's survey points out that the problems with the SIP trunk providers have increased since the 2011 survey, while the problems with edge devices like the Session Border Controller (SBC) and with the IP PBX have remained about the same.
If you've had problems, where have the issues been?
Source: The SIP Survey 2012
Source: The SIP Survey 2012
It is surprising that the SIP trunk providers have been degrading rather than improving their implementations. There are four major problems that stand out as increasing in occurrence, while other issues have changed little or even reduced in frequency.
If you've had problems that were found to be on the SIP trunk provider side, what were they?
Source: The SIP Survey 2012
Source: The SIP Survey 2012
All of the issues in the chart above have been around since the beginning of SIP trunk implementation. It is disappointing that the industry still has not reduced the problem frequency. These are basic implementation issues that should be eliminated during the initialization of the SIP trunks.
It makes you wonder, are the implementation teams overworked, undertrained or both? Or could it be that the providers have not made these problems high priority on their list of improvements? It would seem that the cost to the provider for resolving these problems could be avoided by further investment in the implementation team along with the necessary testing when SIP trunks are installed.
The Problems
The most frustrating problem is trunks dropping connections intermittently. This means the call connection just disappears without any user-generated event causing the problem. The user has no idea what has happened. It may a while before the dropped connection is even detected by the user if the conversation is primarily a one-way monologue.
Registration failures are usually account issues. Poor voice quality can be caused by network problems such as jitter, packet loss, and network latency/delay. Internet Telephony Service Provider (ITSP)/SIP server failures should be rare occurrences.
Resolving the Problems
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.
When registration is not stable, first verify that the Internet connection is operating properly. Check the refresh time in the trunk's overflow and 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. If a firewall is in the connection to the SIP trunk, verify that the firewall will pass and not filter SIP signaling. It could be blocking the signaling.
Even though codec mismatch and one-way audio problems are less prevalent, do not assume that they cannot occur. Test these before initializing the SIP trunk connection. Audio problems are more likely associated with no quality of service (QoS) in use or not enough bandwidth has been 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 persists, then consider terminating the SIP trunk agreement. Server failures should not be a recurring problem.
Preventing the Problems
There will be at least three interested parties to the SIP trunk implementation, IP PBX/UC 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 configuration, 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 they have used the checklist to validate the installations. If there are no checklists, create your own checklists by communicating with other enterprises that have implemented SIP trunks. Use The SIP Survey 2012 to anticipate the issues that can occur. Knowing what has gone wrong at other implementations highlights the issues to be tested.
Some technicians keep tweaking the configuration 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 of the changes 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 eliminating the security features. Codec changes or more or fewer ports on the SBC could be configured improperly.
When the SIP trunk does not work properly, remember that the problems could also be the result of the IP PBX or SBC improperly configured. This makes it more difficult to pinpoint the culprit. If the corrections performed by the SIP trunk provider do not work, enlist the aid of the SBC vendor and IP PBX vendors before you declare the SIP provider as incompetent.
This article is brought to you in part due to the generous support of:
 |
What do you think are the problems with SIP providers’ implementation success?