Reading A Wireshark Capture

Owned by Tom Cavey
Last updated: Jul 14, 2020
4 min read

 
In this article, we will attempt to cover the basics of reading a Wireshark packet capture.


Viewing a Basic Call Flow


This can be a helpful view as it shows the call flow between servers as well as which IP is providing what response. Let's go over the steps:

  • Select Telephony

  • VoIP Calls

Select a call
Flow Sequence
Below is an example of a basic call flow:



If we were reviewing this capture to see where a BYE came from we can see the BYE came from IP 216.221.154.158.


Selecting the Packet

With Call Flow, you can also select the packet which will select the packet in the main Wireshark interface:



Let's go into what these packets offer in greater detail.


Reading a Basic SIP Capture


Below is what you would normally see in a SIP capture:


Highlighted red are the various columns that are clickable. These will rearrange the packets accordingly. Each packet can be selected which will yield different details. Let's start at the Invite packet.

Reading the Invite Packet
Selecting the Invite packet you will see the lower window list the following attributes:
 

  • Frame 1: 1101 bytes on wire

  • Linux cooked capture

  • Internet Protocol Version 4,

  • User Datagram Protocol,

  • Session Initiation Protocol (INVITE)


Each section can be expanded to provide more information. Let's go over the key aspect of the
Invite packet:
Session Initiation Protocol (INVITE)

  • Expand Session Initiation Protocol (INVITE)

  • Expand Message Header

    Here we are able to see the following details:

    The key points to note here are:

  • From - Indicates the source number and the source IP.

  • To - The destination number and the IP the call is being sent to.

  • Call ID - This is the ID generated for this call. It is unique to this call only.

  • Contact - Tells the destination side where to send the next response.

  • Remote-Party-ID - Source number information generated by the Originating party. PRO-


TIP: When you use *67to block your caller ID, this field is still kept intact.
 
Message Body

  • Expand Session Initiation Protocol (INVITE)

  • Expand Message Body

  • Expand Session Description Protocol

    You will see the following details:


    The key points to note are:
    ● Owner/Creator, Session Id (o) - Creator of this session.
    ● Connection Information - Provides the media IP of the originating side ●
    Description, name and address - Provides the port for the media.

    Media

  • Media Attribute - Lists what codecs are being offered by the originating side

    Reading the 200 OK Packet
    The Invite packet starts the call, the 200 OK packet completes the call by answering it. You will find the attributes of the 200 OK packet reflect the Invite packet. This makes sense as the termination side needs to provide a response to the origination side.

    As with the Invite, each attribute can be selected and expanded. Let's go over the key points:
    Session Initiation Protocol (200)

  • Expand Session Initiation Protocol (200)

  • Expand Message Header

    We see a similar breakdown as we see when looking over the Invite:

    Some details are different in the Message Body.

    Message Body

  • Expand Message Body

  • Expand Session Description Protocol
    You will see the following details:

    The key points to note are:
    ● Owner/Creator, Session Id (o) - Creator of this session.
    ● Connection Information - Provides the media IP of the originating side ●
    Description, name and address - Provides the port for the media.

    Media

  • Media Attribute - Lists what codecs are being offered by the originating side.

    In the 200 OK we see the terminations side media IP and port. This is important as the exchange between the Invite and 200 OK tells the origination and termination side how to communicate.

    Reading Media in the Packet Capture
    Here we see media being exchange once the 200 OK is sent:

     
    Lets breakdown the key points to an RTP packet:


  • Internet Protocol Version 4 - This shows the source and destination IP.

  • User Datagram Protocol - Provides the port the packet is sending from and to.

  • Real-Time Transport Protocol - Identifies the Payload type and Payload. Basically, the codec used for the call and data for the audio.



Payload?
The Payload is the audio of the call. Normally the payload will appear as random letters and numbers, the bits of data for the call:

Blank Media Packets
You may see in the Payload a series of F's:

This is dead air or no audio being played. This isn't uncommon at the beginning of the call.
Generally, it is sent to allow time for both sides to connect before two-way audio is opened up.