Browse By

How to read a SIP packet capture using Wireshark

I lot happens in the background when you pick up a handset and call someone with two leading the party – SIP and RTP.

Session Initiation Protocol (SIP) is the control protocol. In other words, it helps establishing the who, where and what of the call.

Real Time Protocol (RTP) is an application layer protocol used for real-time streaming of audio and video data. Most calls involve two streams one for each endpoint allowing bidirectional communication.

A common SIP call flow between two parties looks something like the image below:

SIP flow

Now that we know how does a normal call should look, let’s see it how to find all the same pieces using WireShark – For this example I’m using the sip-rtp-g711.pcap file under WireShark SampleCaptures.

1- Identify all calls in the capture

Go to Telephony > VoIP Calls and select the desired call.

Flow Sequence and Play Streams are shown below, and they provide a quick overview of what happened with the call.

Prepare Filter will display only the SIP and RTP messages related with the selected call and it is time to get our hand dirty!

Packet No. 1 | SIP/SDP | INVITE message from sipp (calling party) to test (called party)

This is an early offer message because it includes the media information indicating codec preference (G.711) and audio port (6000). It is interesting to notice that sipp specifies that it will NOT send audio (recvonly).

Packet No. 2 | SIP | 100 Trying message from test to sipp

Not much going on here, just an acknowledgement that the previous INVITE message was received, and it is being processed.

Packet No. 4 | SIP/SDP | 200 OK message from test to sipp

This message is a confirmation that the call can be establish and codec preference (G.711) and audio port (27942) are also shared. Please notice that the From and To fields did NOT change -this is normal- they get set on the initial INVITE and they will remain unaltered while the call it is being establish.

Packet No. 6 – 430 | RTP | Audio stream(s)

For this capture, the audio stream only flows in one direction (test -> sipp) since the first one identified itself as “sendonly” and the latter as “recvonly” but often you will see a bidirectional communication like on the second example where both endpoints identify themselves as “sendrecv” (check SIP_CALL_RTP_G711).

Packet No. 432 | SIP | BYE from test to sipp

Message indicating that it is time to finish the call with code 16 (Normal Call Clearing). The Call-ID indicates which call needs to end and since it is a new signaling request (end the call) the From and To fields are set by this message but they remain consistent on the final ACK.

Leave a Reply

Your email address will not be published. Required fields are marked *