Troubleshooting SIP Trunk Problems
From Pbxnsip Wiki
Many service providers today offer SIP termination services running over the Internet. This document tries to help you locating problems and gives advice on getting a stable connectivity. Please see also a PowerPoint presentation that we put together on this topic (http://www.pbxnsip.com/download/qos.ppt).
If you can not register at all, check the following items:
- Is your password correct? Are you using the right authentication?
- Does your ISP support SIP? You can cross check easily by trying to register a soft phone (e.g. Xten from http://www.counterpath.com). If you can't register the soft phone, you will most probably also not be able to register a SIP trunk as well.
- If there is a firewall between the PBX and the registrar, it might be worth checking the traffic before and after the firewall. Some firewalls filter SIP traffic, and this can cause problems which are really hard to find.
In some environments, registration is not stable. Symptoms may including being able to call in, while other times, you don't get through. This is typically caused by a long refresh interval that is too long.
In such cases, you can override the refresh time in the setting "Keepalive Time" for the trunk. Try setting the value to 20 seconds.
There are still operators who believe that sending refresh traffic (white space, OPTIONS) from the ITSP to the PBX solves the problem. Because those keep-alive packets can get lost (e.g. when there is a lot of traffic on the line), this kind of service is unstable and extremly difficult to debug. Also, there are firewalls that do not accept outside-initated traffic as keep-alive traffic. Better set the registration time to something like 20 seconds.
If your internet connection is not stable, don’t be surprised that your registrations are also not stable. There are several tools available that monitor the quality of your internet connection. In case that you have trouble, we recommend that you start using such a tool.
One-way audio means that one party can hear the other, but is not heard. This is typically caused by the router/firewall that allows that the audio packets are sent to the service provider, but misinterprets the incoming traffic as attack.
Most service providers today deal with this topic my learning from what IP address and port they receive RTP packets. They simply send the traffic back to that destination and then two-way audio is established. If the PBX is run on public IP, it does the same trick to make VoIP phones work behind firewalls.
This usually works when routers are used that are not aware of SIP. Some routers try to “help out” and change the packets – which usually causes an even bigger chaos. If you see a flag that mentions SIP or UPnP you may try to turn this feature off and see if the voice stream passes the router without problems.
Especially more advanced firewalls offer serious SIP support. These firewalls would like to know if the data stream that they are relaying is audio data or there is a Trojan horse uploading valuable corporate data. Fortunately, their SIP support is usually better than on low-end devices and turning the SIP inspection on really increases your corporate security. If you are using such a firewall and experience problems, check if you are using the latest firmware and it is also worth a try to temporarily disable the SIP features to see if that changes anything.
There was a time when operators were trying to fix the problem by asking clients to use so-called “STUN” servers in the Internet. But because there are so many complex scenarios (and a lot of frustrating support), it seems that almost all of the service providers gave up on that approach and instead just to that RTP address learning trick. If your service provider insists that you must provide a routable IP address, the only serious advice is to get a (real) public IP address or change the service provider.
For more information, also check One-way Audio.
Poor Audio Quality
Poor audio is exemplified by the voice stream getting interrupted from time to time. This is a sign that you have some serious problems with your Internet connection. You can check the line quality by pinging a nearby location over a longer period of time and watch the delay in the responses. If there is a lot of jitter, you will probably hear that in conversations.
- If you are sharing the line with other applications (like email and web), you must make sure that the quality of service (QoS, see Type of Service) is respected in both directions of the call. That means that you must make sure that all components that are between the PBX and the Internet line respect QoS.
- Also your service provider must respect QoS bits. If you get the Internet connection from the same service provider, it is usually relatively simple for him to provide that service for you. If you are running your traffic on a different service provider, it is usually difficult to get such a commitment from the service provider carrying the traffic.
- If you force a specific codec on a trunk, the PBX probably may have to perform transcoding. While transcoding might help to save bandwidth (and this way reduce the risk of packet loss and delay), every transcoding reduces the audio quality. Especially when transcoding from one low-rate codec to another low-rate codec, the quality suffers significantly. Therefore forcing a specific codec on a trunk is always a trade off.
- Sometimes audio problems are caused by networking equipment that cannot deal with the packet load or is just running for too long. There were cases reported where a reset of switch solved poor audio quality problems.
DTMF Not Working
DTMF is usually transported over out-of-band DTMF (RFC 2833). There are still some providers who believe that this is not necessary. But because RTP stream might loose packets, inband DTMF detection is an unnecessary burden and source for problems on the PBX. Make sure that your service provider supports DTMF according to RFC 2833.
In cases when the quality was sporadically not okay, we found that it is extremly useful to use a network monitoring tool that helps to detect the problems. Here is a list of tools that we know (not neccessarily complete, please send us an email if you know another tool):
- "Observer 12" from Network Instruments (www.networkinstruments.de)