Check SIP Issues Using Wireshark, TCPDUMP and TShark

VoIP communications, from a business point of view, is an interesting alternative to standard telephony. It allows you to scale and deploy your telecommunications infrastructure as needed, thus allowing you to save major long-term costs.

From a technical point of view, this alternative can be daunting and challenging since it involves the management of your network, the connectivity with many devices outside of your network (in other words, out of your control), the knowledge of many protocols and the appropriate tools to troubleshoot.

This article focuses on troubleshooting SIP trunks by interrogating the Session Initiation Protocol (SIP) signaling, as signaling is the most important step for establishing a connection between your switch and the person you are trying to reach.

The SIP Protocol is in charge of negotiating the signaling between point A and point B. There are a few SIP codes we need to know in order to understand how/what to troubleshoot.

Figure 1.1

Now that we have the most common scenarios described in Figure 1.1, we need to find these messages on our switch. There are a number of “open source” tools that are available to capture SIP messages (tcpdump, and tshark) and analyze them (Wireshark). These can be installed based on the OS your switch is operating on. A simple web search will provide you with the right links, furthermore, below are some links that worked for us.

• tcpdump for Linux
• tcpdump for Windows
• tshark for Linux
• tshark for Windows
• Wireshark for Linux
• Wireshark for Windows

Example 1

Issue:

Customer can’t connect any call at all.

Analysis:

If other customers are having the same issue, then you have an issue with your switch. If this is the only one customer experiencing this issue, then you can either check the following:

• Ping your customer’s IP to make sure connectivity is up

• Run a tshark command to see if your server is rejecting traffic

  • ie. tshark -i wlan0 port 5060 and host 1.2.3.4

• Where:

  • -i represents your internet interface (for the example we are using wlan0)
  • port represents the traffic you are capturing (5060 is SIP)
  • host represents the IP you are trying to capture
  • more examples here

• With the tshark command, you will be able to see the SIP negotiation in real-time and will be able to determine the root cause of the issue based on the Figure1.1

Example 2

Issue:

Customer has issues with dropped calls.

Analysis:

It is necessary to know what end sent the Bye message on the sip codes. If this is a constant issue you would need to run a trace on your customer’s IP, so you can retrieve a PCAP file and analyze it on Wireshark

• Run the tcpdump command

  • ie. tcpdump -i eth1 -w test.pcap port 5060 & host 1.2.3.4

• Where:

  • -i represents your internet interface (for the example we are using eth1)
  • port represents the traffic you are capturing (5060 is SIP)
  • host represents the IP you are trying to capture
• Once the trace is completed open the PCAP file and analyze SIP signaling to find out where the Bye message came from.
• Based on your findings you can either escalate with your VoIP service provider or let the customer know that the issue is not on your end.

Troubleshooting SIP with signaling relies on your ability to capture the information needed to find a root cause of the issue and also your ability to interpret the results of the packet capture. It is always good practice to try to recreate the issues, as most of the times the situations can be replicated. As far as the tools go, there are more sophisticated ones available, but the ones you really need are free and will get you most of the way there with troubleshooting production traffic to find the root cause.