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:
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.
I am a Cisco Certified Network and Collaboration Engineer (CCNP) with over 9 years of experience and a passion for all things technology. I have spent most of my time mastering the world of networking and collaboration, but still find myself dabbling in cloud computing and programming.
Solving problems and learning something new in the process is my favorite part of the job. Having a depth understanding of the technology is what has driven my success.
