SIP diagnostics using WireShark

Modified on Fri, 8 Jul, 2016 at 1:28 PM

If your organization uses a SIP-based VoIP solution, then you've probably had things go wrong: users can't connect to the system, or the call quality is poor. When this happens, you need to troubleshoot to resolve the problem.

To troubleshoot your SIP-based VoIP system, you first need to see exactly what's going on with the VoIP traffic traveling over your network. A simple way to do that is to use a free, open source traffic sniffing and analysis tool called Wireshark. The software lets you see every packet traveling over your network and can filter out irrelevant packets to concentrate on the ones of interest. Let's explore how you can begin to use Wireshark to troubleshoot SIP-related problems.

Getting started with Wireshark

For SIP-based VoIP troubleshooting, you're likely to be interested in two types of packets: Session Initiation Protocol (SIP) packets--which, as the name suggests, do the work of setting up and tearing down a call--and Real-time Transport Protocol (RTP) packets, which carry the voice data.

User unable to connect to SIP server

Let's begin by troubleshooting a user who's having a connection issue with an IP phone.

At first, you'll probably see a bewildering amount of traffic traveling over the network in Wireshark. Filter this to show only SIP traffic by typing "sip" into the filter box at the top of the Wireshark window. You may also want to filter the display to show only traffic to and from the problem phone's IP address.

The screenshot below displays the SIP traffic generated from 192.168.1.150 as it tries to connect to a SIP server. Wireshark shows that traffic is successfully reaching the SIP server from the IP phone, so the problem is not the connection between these two points. (If the IP phone was a softphone running on a PC, the connection problem could have been caused by a firewall on the PC preventing the SIP traffic from reaching the network, for example, but we can rule this out, since the SIP server and the phone are communicating.) Since the phone tried four times to log on to the SIP server before giving up, it's likely that in this case we have an authentication problem. The SIP phone has most likely not been configured correctly.

After the phone is reconfigured correctly, it can successfully authenticate with the server:

User unable to make VoIP calls

Next, let's troubleshoot a user who can authenticate onto a SIP server, but who can't make calls.

The screenshot below shows what a successful call setup and teardown should look like in Wireshark:

Inspecting the traffic flows for a call as it is set up, connected, and torn down is easy using Wireshark. To do this, select VoIP Calls from the Telephony menu, choose a call, and click on Flow.

The screenshot below shows a typical SIP-initiated conversation lasting about 20 seconds:

Calls can fail for the most obscure reasons. For example, some SIP gateways might expect some of the call setup information in one format, while another part of the SIP infrastructure provides it in a different one.

The screenshot below shows a SIP invite request packet.

Within the header, the Allow property is displayed, in this case with all the elements on one line. But if another part of the infrastructure expects them as different elements, the call might fail. The most practical way you can troubleshoot this type of problem is by inspecting the packets in a tool like Wireshark to figure out what's going wrong with the SIP call.

User experiencing poor SIP call quality

Unacceptable SIP call quality may come from too many packets being dropped, perhaps because of network congestion. It may, however, also be nothing to do with the network and instead involve another issue, such as a hardware problem in the phone itself.

To investigate this, change the filter from "sip" to "rtp" to see the voice traffic.

Wireshark is smart enough to "understand" RTP. The screenshot below shows a VoIP conversation which Wireshark understands has been made using the G.711 codec.

Click on a packet and then choose RTP-Stream Analysis from Wireshark's Telephony menu to call up information about the call of which the packet you clicked was a part.

In this case, the proportion of lost packets was 0 percent and the mean jitter, a measure of the variation in the delay between packets arriving, is low.

This most likely rules out network conditions as the cause of poor call quality, which in this case is more likely to stem from some external factor, such as the aforementioned hardware problem.

SIP call reconstruction

Wireshark also allows you to reconstruct a call from its packets, letting you hear the sound quality for a given call with given call statistics, such as jitter and packet loss. (It's worth mentioning, however, that doing this may have legal implications.)

To reconstruct a call, click Player from the Stream Analysis window, select which side of the conversation you want to hear--or both sides--click Decode, and, finally, click Play.

This just scratches the surface of how Wireshark can help you analyze and troubleshoot VoIP call issues. The software is certainly not a panacea for all SIP-based, VoIP-related problems, but by allowing you to see exactly what's happening on your network, it is an invaluable tool to use for general troubleshooting and pinpointing of trouble spots as they arise.