How to trace VoIP calls using Wireshark?

To trace a VoIP call using Wireshark, use the menu entry telephony, the select VoIP calls, you will see the SIP call list. You will be able to see the start time and time stop of every call. As well as the initial speaker and IP address of the caller. Besides that, you will see the caller id and callee id in the form and top URL.

 Wireshark is a network capture tool that analyses packets. To make a call or reproduce the specific action that you wish to analyze (for example, registration with a VoIP provider, or an outbound call). You can also use Wireshark to capture traffic on cloud PBX. Wireshark capture packets can be used for SIP traffic analysis, software, communications, Local network development. 

How do I filter VoIP call using Wireshark?

How do I analyze VoIP calls using WireShark?

To be able to access the VoIP calls analysis, use the menu entry, telephony, Voice over IP telephony calls the current Voice over Internet Protocol supported protocols are :

  • MGCP
  • ISUP
  • H323
  • SIP
  • SDP 

Each VoIP call list shows the following information per call.

Stop time: This is the stop time of the call

Start time: This shows the start time of the call

Initial speaker: Shows the IP address source of the packet that started the call.

From: For ISUP and H323 calls, this is the calling number. For SIP calls is the ‘From’ field of the InVITE for UNISTIM, Terminal ID. For MGCP calls, the Endpoint of calling number.

To: For ISUP and H323 calls, this is the called VoIP number. For SIP calls, this is the ‘To’ field of the INVITE. For UNISTM, this is the dialed number. For MGCP calls, the dialed number or Endpoint.

Protocol: This will show any of the protocols listed in the previous section.

Packets: This will show the number of packets involved in the call.

State: This is the current call state. The possible values are:

  • Rejected: The call was released before connection by the destination side
  • Completed: The call was connected and then released
  • Call setup: Call in setup state (Proceeding, Progress or Altering)
  • Canceled: Meaning the call was released before connection from the originating caller
  • Ringing: Means the call is ringing (MGCP calls only support it)
  • Incall: To indicate the call is still connected.
  • Unknown: This shows the call is in an unknown state

Comment: An extra comment, this is protocol dependent. For H.323 calls it shows if the call uses Fast Start or H245 tunneling

Filtering VoIP call

To prepare a filter for a specific call, choose the desired calls, and press the prepare filter button. This will build a filter in the main Wireshark windows to filter the packets associated with this call. This is most essential when you want to connect ISUP calls or SDP message following CIC value.

To graph analysis, one or multiple voice calls from the Voice over IP list, choose them from the record and then click on the graph button.

The graph will contain the following information:

  • Shows the TCP or UDP packet source and destination port per packet
  • The RTP traffic is resumed in a wider arrow with the corresponding codec
  • The label on top of the arrows shows a message type. When accessible, it also shows the media codec
  • An arrow showing the direction of every packet capture in the calls
  • Up to ten columns portraying an IP address 
  • All packets that are from the same call are colorized with the same color
  • The comment column has protocol dependent information:


  • The release message indicates the Q.931 release cause code
  • Fast start and H245 Tunneling on and off for the packet
  • The setup message indicates the calling and called number

SIP invite

  • Indicates if the packet is a request or a status message
  •  The invite message also indicates the from and to fields
  • To invite message also portrays the From and To fields


  • The format is as follows: NetworkID-Destination Point Code, CIC, Network ID-Originating Point Code


  • Shows the MCCP endpoint ID and if the packet is a request or response message


  •  Details of the message and the sequence


  • Indicates the number of RTP packets in the stream, the duration in seconds and the SSRC field

When you are pressing a packet in the graph, the chosen frame will be selected from in the Main Wireshark window.

How to play VoIP calls in Wireshark?

To playback, the RTP audio stream of one or multiple calls from the Voice over IP List, select them from the record and then press the “Player” button:

Select an initial value for the jitter and then click the decode button. The jitter buffer reproduced by Wireshark is a standard size jitter buffer and can effectively be used to reproduce what clients can efficiently hear during a VoIP call. You can now see all RTP streams for the calls that are chosen.

Note that all RTP packets are dropped since the jitter buffer is reported, as well as the packets that are out of sequence. Pressing the play button plays the RTP streams from within Wireshark. A progress bar shows the position in the stream and is synchronized amongst all RTP streams that are played.

How to analyze a SIP call using Wireshark?

Troubleshooting VoIP QoS: Solving common packet loss problems linked to VoIP with Wireshark

When we face a problem, such a failure or no audio in VoIP SIP, usually we have to get the PCAP file and check the packets loss. This section is about analyzing sip messages and calls in Wireshark.

In case your company uses a SIP-based VoIP software, then you have possibly had things go wrong, and users cannot connect to the system, or the call quality is poor or unified communications tools cannot integrate well. When this happens, you have to troubleshoot to resolve the problem. PCAP dump file contains all the protocols travel in the network card, Wireshark for VoIP has expressions to filter the packets so that can display the particular messages for the specific protocol. 

For SIP based VoIP troubleshooting, you will possibly be interested in two kinds of packets, Session Initiation Protocol (SIP) packets, and real time Transport Protocol, RTP packets, which carry voice data.

SIP call analysis: Solving traffic over VoIP network

In case you are having a connection problem with an IP phone, you will possibly see a huge amount of traffic traveling over the network in Wireshark. Filter this to show only SIP packets by typing SIP into the filter box at the top of the Wireshark window. You might also want to filter the display for capturing traffic only to and from the problem phone’s IP address.

Examining call flow with Wireshark

Now let’s troubleshoot a user who can authenticate onto the SIP trunking server but who cannot place calls. Inspecting the VoIP traffic flows for a call as is configured, connected, and torn down is easy using Wireshark. To do this, choose VoIP phones calls from the Telephony menu, select a call, and click on SIP call flow.

Phone calls can fail for the most common reasons. For instance, some hosted PBX gateways may expect some of the call setup information in one format, whereas another part of the SP infrastructure offers it in a different one. Alternatively, you can join a technology partner portal; they will manage your phone system and check packet losses, including troubleshooting on your behalf.

RTP stream analysis

When you have a voice problem, we can check the following issues with Wireshark:if the RTP stream exists, is the RTP stream decoded in the right codec if the RTP stream sends and receive on the right IP address and port. And if the RTP stream can be sent at the right time.

If you are experiencing poor voice quality, you change the filter from SIP to RTP to see the voice traffic. Wireshark is smart enough to understand RTP analysis. Click on a packet and then select RTP stream analysis from Wireshark’s Telephony menu to call up data about the call of which the packet you clicked was a part. You can also capture VoIP PBX traffic to determine the RTP packets. In this situation, the proportion of lost packets was zero percent, and the mean jitter, an estimate of the variation in the delay between packets arriving, is low.

Scroll to Top