Notice: This blog entry has nothing to do with elephants sipping water through trunks.
Now that that's out of the way, many organizations have migrated to SIP trunks due to the savings that can be realized with these services, yet when problems arise they don't know where or how to troubleshoot them.In order for a SIP trunk to function, three different components are typically involved:
Troubleshooting each of these components requires different approaches.
SIP Trunk monitoring
Depending on what the problem is, you will need to troubleshoot it with a different methodology. Generally, two different types of problems can occur with SIP Trunks:
Each type of problem usually relates to a different protocol having problems.
The problem may lie in the SIP handshake that occurs between these two devices.
The best way to analyze this is to set up a packet capture between the two SBCs and watch the communications between the gateways to see if there communications errors exchanged between the SBCs that might lead to a resolution.
The good news is that SIP response codes are well-defined:
1xx — Provisional Responses
2xx — Successful Responses
3xx — Redirection Responses
4xx — Client Failure Responses
5xx — Server Failure Responses
6xx — Global Failure Responses
For detailed response codes, refer to Wikipedia:SIP Response Codes.
If there is packet loss that is preventing calls from being established, SIP will perform a limited number of retries before giving up, but the lost packets will be seen in the packet capture trace. Troubleshooting the packet loss for the SIP setup part should be done the same way you would troubleshoot the SIP Trunk call quality problems in the next section.
Quality problems are usually related to calls that are established and may be fine for a short period of time before issues start to occur. Typically, the quality problems relate to clipping of words or phrases, or entire missing words or phrases.
The transient nature of these sorts of problems can be related to:
Typically these statistics can be monitored via the SBC's own management software, or via SNMP variables.
The SIP trunk provider may provide some visibility into their endpoints and ability to handle traffic. Usually they will prevent a customer from seeing too much, as they never want to expose that they have problems when dealing with heavy loads. The best piece of information you can gather on their performance is to measure when you have problems with them, and how many calls your SBC has with them at any time.
This is typically the source of call quality problems, as many issues can exist in the network elements involved between the SBCs.
Troubleshooting these elements typically involves using specialized single-ended call simulation tools, and route-path evaluation tools like those included in PathSolutions TotalView.
The best practices are covered in this recorded video made for IAUG:
VoIP troubleshooting problems can be prevented if the right information is brought to bear about your network's performance and configuration.
Review our white paper or contact us with questions about how PathSolutions TotalView can make VoIP/UC troubleshooting easier.