Wireshark 
Wireshark is an open source network analyzing utility that is useful for diagnosing and resolving network issues. It can be especially helpful in VoIP telephony as packet captures provide insight into specific protocols used for internet phone calls. Wireshark can be used to not only obtain network packet captures but also analyze existing captures. The purpose of this article is to provide an overview of this program to assist users in obtaining and interpreting packet captures.
Obtaining a Capture
To obtain a capture using Wireshark, you must ensure you have the program installed on your machine. If you do not yet have it, you can get it here for Windows/Mac: {+}http://www.wireshark.org/download.html+ If you are using Linux please see the information here: {+}http://www.wireshark.org/docs/wsug_html_chunked/ChapterBuildInstall.html+
Once you have Wireshark installed you can apply various filters to obtain the desired information. As a rule, it is best to filter less when obtaining the capture and apply the filters when examining the capture. Limiting the filters while capturing ensures you do not miss valuable information such as RTP traffic.
To capture traffic on a Windows machine, open Wireshark and click 'Capture->Interfaces', select the interface you wish to capture on and click 'Start'. You can also click Capture->Options and experiment with the various settings.
To capture traffic on Linux, you would type the following command in the CLI: (without the tags) where –i eth1 represents the interface you wish to capture on and host represents the IP address of the traffic you wish to capture. There is a myriad of syntax options that can be used when capturing packets. For example, if you wish only to capture SIP packets on a specific telephone number, you can use (without the tags). Notice the upper-case T and F in the syntax; this is necessary, otherwise you will receive an error. The single quotes are also necessary. Note the difference in the first example when capturing just on the IP address; there are no single quotes or upper-case letters. You will have to experiment with syntax to determine what works best for you but as previously mentioned it is best to filter less when creating the capture and then apply the filters when reading the capture. Essentially, any filter that can be used when obtaining the
capture can be used when reading it. For instance, the aforementioned sip.To/From example could be entered in the 'Filter:' text box in the Wireshark GUI to find any SIP packets to or from the specified number.
Notice that the background color of the filter is green; however, also take note that unlike the command line, the filter box does not contain the single quotes. Wireshark is intuitive enough to guide you in your filter syntax. Adding the single quotes creates a red background color to indicate the syntax is invalid:
Typing a command line as outlined above will not save the information to a file. You must add the following -w filename.cap where 'filename' can be anything you wish to identify the capture. Here is an example of CLI syntax that would be written to a PCAP file:
If you have Wireshark installed, your syntax would change to tshark instead of tethereal.
Reading a Capture
(Note: there are literally hundreds of options when dealing with PCAP files and covering them all is beyond the scope of this article. We will attempt to cover the basics)
Once you have obtained a PCAP, you will need to read the information contained within to troubleshoot specific issues. The size of the capture as well as the information you are seeking will determine the filters used. Let's start with a basic SIP only PCAP. This is a basic PCAP containing only SIP information and was captured using 'sip.To contains 8774786471 or sip.From contains 8774786471' -w Basicsip.cap
Notice the various columns highlighted above. These are clickable options that will rearrange the packets accordingly. The time option can be changed with the main menu. Click View->Time Display Format and choose the desired setting. This can be helpful for checking the time between certain events (time between INVITE, 183 Ringing, etc.). Also notice at the bottom the + sign next to 'Session Initiation Protocol'.
Clicking the Session Initiation Protocol allows you to drill down into the SIP packets and pertinent information is contained in both the Message Header and Message Body sections. Following is a brief description of the information for each.
The Message Header contains the basic information of a SIP call, for example:
To: <sip:14125322201@64.136.164.33> number being dialed)
From: <sip:14126096089@64.136.174.30>;tag=sansay90285357rdb2907 (the number called from)
Call-ID: 25350276-0-3048653530@64.136.174.226 (a unique identifier for each call)
Contact: <sip:14126096089@64.136.174.30:5060> (contact header tells where to send next response)
Session-Expires: 1800;refresher=uac (indicates when the call(session) will end if not refreshed)
P-Asserted-Identity: <sip:4126096089@10.103.102.32> (method used to pass anonymous as callerID on SIP calls)
The above represents the Message Body
Owner/Creator, Session ID (o): Sansay-VSXi 188 1 IN IP4 64.136.174.30 (creator of the session)
Connection Information (c): IN IP4 209.165.1.198 (where the sending side is requesting the receiving side send audio/RTP)
Media Description, name and address (m): audio 28490 RTP/AVP 18 0 101(this is the port requested for audio (28490) as well as the codecs being offered in the INVITE (18 is G.729, 0 is G.711, and 101 is RFC 2833 for DTMF, you can find an explanation of codec payload types here: {+}http://tools.ietf.org/html/draft-ietf-avt-+profile-interop-00)) You will also see the codecs listed as the Media Attribute as displayed above:
Media Attribute (a): rtpmap: 18 G729/8000
Media Attribute (a): rtpmap: 0 PCMU/8000
Media Attribute (a): rtpmap: 101 telephone-event/8000
An additional Media Attribute is (a); ptime:20 and represents the time between RTP packets, in this case, 20 ms.
Basic Filter Options
Once you understand a basic SIP capture, you are now ready to filter a larger capture to isolate a specific call or call leg. A useful feature of Wireshark is that you can listen to the call using the included player. This comes with one caveat. Since G.729 requires licensing, calls using this codec will not be able to be heard using the player. To listen to a call in Wireshark, click Telephony>VoIP Calls from the main menu. This will open another window displaying all the calls contained in the capture (note: the PCAP must contain the RTP to be able to listen to the calls.) From the newly opened window, select one of the calls from the list and click the 'Player' button. Another window will open; click the 'Decode' button. The player will open showing the audio streams of the call. You will need to place a check in the checkboxes; you can listen to either or both streams. The window containing the audio streams will indicate which side is sending and which side is receiving for each stream. As previously mentioned, each call will have a unique Call-ID. You can use this Call-ID as a starting point to isolate a specific call. For example, we have a
capture containing 8500 packets and three VoIP calls and want to isolate one of these calls. You could scan the capture visually for the INVITE to that number or use the sip.From or sip.To syntax in the filter box. This will isolate all SIP traffic to/from the number.
Here is what the capture looks like before the filter is applied:
After the filter is applied:
Now we need to get this call in its complete form with the RTP. To do this click the INVITE (with the filter applied)>Session Initiation Protocol>Message Header and locate the Call-ID.
Right-click and choose 'Apply as Filter->Selected'. (Note: Depending on the number of calls to the desired number, this step may not be necessary. For example, if there was only one call in the PCAP to the number, the previous filter would isolate that one call. If there are multiple calls, you would need to use the Call-ID filter options to isolate each call to the number). The next step is to determine the audio ports in use for the call and add that information to the existing filter. Recall that the audio ports can be found in the message body of the Session Initiation Protocol section in Wireshark. The INVITE contains the audio port from the sending side and the 200 OK contains the audio port from the
receiving side. First highlight the INVITE, then click Session Initiation Protocol->Message Body>Session Description Protocol and look for the audio port:
This information can now be added to the existing filter by clicking in the filer box (ensure you are at the end of the line) and add the following 'or udp.port==16330' (without the single quotes).
Do the same for the port in the 200 OK:
Next apply the complete filter to the PCAP by clicking the 'Apply' button to right of the filter text box. The complete call including the SIP and RTP will now be visible. If you are new to Wireshark, it can be helpful to save filtered captures as separate files. You can do this by clicking File->Save As; give your filtered capture a filename, change the radio button 'Captured' to 'Displayed' and click the 'Save' button. You can now open your newly filtered call as a separate file containing only the call you wish to analyze.
Additional Information: Things to Look For
There are some common issues to look for when analyzing VoIP calls. The filter to start with will depend on the issue you are experiencing. Generally, you only need filter with RTP for audio issues. For example, if you are experiencing one-way audio, you will need the RTP to determine the cause. Some common reasons for one-way audio are:
- You are requesting audio on an internal IP address (you will see this in the Connection Information in the
...
- Message Body of either the INVITE or 200 OK packets)
- You are attempting to use G.729 without proper licensing
- You do not have the proper UDP ports open on your firewall (this would give the appearance in the capture of the other side not sending audio)
- One side not sending RTP
- Codec mismatch--one side is not sending the agreed upon codec while the other side does not
Another audio issue is jitter/choppiness. This can be caused by a number of factors but you can check if the issue is on your network using Wireshark. To do this use the techniques outlined in this article to isolate the affected call. You can then do the following: Click an RTP packet, next click Telephony->RTP->Stream Analysis. The corresponding window that opens will contain a column labeled 'Delta'. This is the length of time between RTP packets, also known as ptime. Check to see that the delta stays consistent throughout the capture by scrolling through packets. If you notice inconsistency in the delta, check to ensure there are no bandwidth issues on your network. Next run traceroutes between your network and the media gateway in use for the call to pinpoint any issues.
If you are not having audio issues but are having other problems such as call drops, no connection, etc., you will not need to filter using RTP. A simple Call-ID or sip.To/sip.From filter
should be enough to ascertain the necessary information in the PCAP. A normal SIP call should be as follows:
Ensure that your capture has normal flow and if not, analyze why this might be.
Seemingly Infinite Possibilities
Wireshark has seemingly infinite possibilities for analyzing network issues. To cover them all is beyond the scope of this article. You will need to experiment with various filter syntaxes as well as the tools Wireshark makes available in its interface. The information provided in this article should allow you to begin to understand how to obtain and analyze a basic PCAP.