How to Capture VoIP Traffic With Wireshark (and What to Do With It)

Most VoIP troubleshooting eventually leads to the same place: you need to see what is actually happening on the wire. The phone says it is registered. The provider says the trunk is up. The call still fails, or the audio sounds terrible, or calls drop after exactly 30 seconds. The only way to know what is really going on is to look at the packets.

Wireshark is the tool for this. It is free, it runs on every major operating system, and it has built-in features specifically designed for VoIP analysis. This guide covers how to capture VoIP traffic, how to filter it down to what matters, and what to do with the capture once you have it.

Before you capture: where to tap

Where you place the capture determines what you can see. This matters more than any filter or setting.

On the phone itself: If you are troubleshooting a single phone, some IP phones have built-in packet capture features (Polycom and Yealink both support this). The advantage is that you see exactly what the phone sees. The disadvantage is that phone-side captures are often limited in size and duration.

On a mirror port: The best general-purpose approach. Configure a SPAN or mirror port on your managed switch to copy all traffic from the phone's port (or the uplink to the internet) to a monitoring port where your capture machine is connected. This lets you see all traffic without affecting the phones.

On the PBX: If you are running a software PBX like Asterisk or FreeSWITCH, you can capture directly on the PBX server. This shows you both sides of every call (the leg between the phone and the PBX, and the leg between the PBX and the provider). tcpdump is usually the fastest option here:

tcpdump -i eth0 -w /tmp/capture.pcap -s 0 port 5060 or portrange 10000-20000

This captures SIP signaling on port 5060 and RTP media on the typical RTP port range. Adjust the port range to match your PBX configuration.

On the WAN interface: If you suspect the problem is between your network and the provider, capture on the router or firewall's WAN interface. Some firewalls (pfSense, OPNsense, FortiGate) have built-in packet capture. This is especially useful for diagnosing NAT traversal and firewall issues.

Starting the capture in Wireshark

Open Wireshark, select the correct network interface, and start capturing. If you know you only need VoIP traffic, set a capture filter before you start. Capture filters are applied at the wire level and keep your file small:

udp port 5060 or udp portrange 10000-20000

This captures SIP signaling and RTP media for a typical deployment. If you are unsure of the port ranges, skip the capture filter and capture everything. You can filter later using display filters. The file will be larger, but you will not miss anything.

Let the capture run while you reproduce the problem. If the issue is intermittent, you may need to let it run for a while. For large captures, consider rotating files:

tcpdump -i eth0 -w /tmp/voip-%H%M.pcap -G 300 -s 0 port 5060 or portrange 10000-20000

This creates a new file every 5 minutes, which makes it easier to find the window when the problem occurred.

Filtering the capture

Once you have a capture, open it in Wireshark and apply display filters to isolate VoIP traffic.

See all SIP traffic

sip

This shows every SIP message in the capture: INVITEs, 200 OKs, BYEs, REGISTERs, and everything else. On a busy system that is thousands of messages, most of them routine keep-alives — Reading a SIP Trace Without Losing Your Mind covers how to cut through the noise and isolate the call you actually care about.

See SIP and RTP together

sip || rtp

This shows both signaling and media streams. Useful when you need to correlate call setup with audio delivery.

Filter to a specific call

Every SIP call has a unique Call-ID header. Once you find the call you are interested in, filter by it:

sip.Call-ID == "[email protected]"

Filter to a specific phone

If you know the phone's IP address:

ip.addr == 10.0.0.50 && (sip || rtp)

Find failed calls

sip.Status-Code >= 400

This shows all SIP error responses: 4xx client errors, 5xx server errors, and 6xx global failures.

Using Wireshark's VoIP features

Wireshark has two built-in features specifically for VoIP analysis.

VoIP Calls window

Go to Telephony > VoIP Calls. This shows a list of every call in the capture with the caller, callee, start time, duration, and status. You can select a call and click "Flow Sequence" to see a ladder diagram of every SIP message in the call, which side sent it, and the timing between messages.

This is the fastest way to find a specific call and understand the signaling flow. Failed calls show up with their error codes. Calls that set up but never got a BYE might indicate a timeout or network partition.

RTP Streams window

Go to Telephony > RTP > RTP Streams. This shows every RTP stream in the capture with the source and destination, codec, packet count, lost packets, jitter, and duration. Select a stream and click "Analyze" to see per-packet timing, sequence gaps, and jitter graphs.

This is where you find audio quality problems. High jitter, packet loss, or sequence gaps in the RTP stream directly explain choppy audio, robotic voices, and gaps in conversation.

What to look for

Call setup failures

Open the VoIP Calls window and look for calls with error status codes. The most common:

• 403 Forbidden: Authentication failure. Check credentials.
• 404 Not Found: The dialed number does not exist on the far end.
• 408 Request Timeout: No response from the remote side. Network connectivity issue.
• 480 Temporarily Unavailable: The destination is not answering. Could be a phone that is offline.
• 486 Busy Here: Normal busy signal.
• 503 Service Unavailable: The provider or PBX is overloaded or down.

Our SIP Response Code reference has plain-English explanations and troubleshooting steps for every code.

One-way audio

If calls connect but audio only works in one direction, look at the RTP streams. You should see two streams per call (one in each direction). If you only see one, the other direction is being blocked by a firewall or NAT issue. Check the SDP in the INVITE and 200 OK to see what IP addresses and ports each side is advertising for media.

Audio quality problems

In the RTP Streams window, look at the lost packets and max jitter columns. For acceptable voice quality, you want less than 1% packet loss and jitter under 30ms. If you see high numbers, the issue is in the network between the two endpoints, not in the phones or the PBX.

Skip the manual analysis

Reading through SIP headers and correlating RTP streams by hand is valuable for learning, but it is slow when you are in the middle of an active outage and a customer is waiting.

Our PCAP Analyzer does this automatically. Upload your pcap file and get structured results: every call identified, every RTP stream analyzed, quality metrics calculated, and common problems flagged. Analysis runs as a background job on our servers, and your capture is removed from the processing queue automatically once the job clears — see the privacy policy for specifics.

For an even faster read on what went wrong, SIP Call Stories generates plain-English diagnostic narratives for every call in the capture. Instead of reading SIP headers, you get a story: "Call from 2125551234 to 2125555678 failed with 408 Request Timeout after 32 seconds. The INVITE was sent but no provisional response was received, suggesting the remote endpoint is unreachable or the request was lost in transit."

Both tools accept standard pcap and pcapng files from Wireshark, tcpdump, or any other capture utility.