Wireshark for VoIP: A Practical Guide to Capturing and Analyzing SIP/RTP

Wireshark is the standard tool for diagnosing VoIP problems. When someone says "the calls sound bad" and you need to know why, a packet capture tells you exactly what happened on the wire. No guessing, no "it might be the network" — the packets tell the story.

This guide covers the practical workflow: capturing VoIP traffic, filtering it efficiently, extracting quality metrics, and identifying the most common problems. If you want the theory behind SIP signaling, see Reading a SIP Trace: Practical Troubleshooting. This post is about using Wireshark effectively.

Setting up the capture

Where to capture

Where you place the capture point matters. Capturing on the wrong device gives you incomplete data.

On the VoIP phone's subnet — captures everything the phone sends and receives. Best for diagnosing phone-specific issues like registration failures, codec negotiation, and audio problems on a single device.

On the router/firewall — captures traffic as it enters and exits the network. Best for diagnosing NAT issues, SIP ALG problems, and WAN-side quality issues. Many firewalls (pfSense, FortiGate, SonicWall) have built-in packet capture tools that export to pcap format.

Port mirror / SPAN port — configure your switch to mirror the VoIP VLAN traffic to a port where your Wireshark machine is connected. This captures all VoIP traffic on the network without affecting performance. Best for capturing multiple calls or intermittent problems.

Capture filter

Use a capture filter to limit what Wireshark records. VoIP traffic is a mix of SIP signaling (call setup and teardown) and RTP media (the actual audio). Capture both:

port 5060 or udp portrange 10000-20000

This catches SIP on port 5060 and RTP on the typical media port range. Adjust if your system uses different ports. If you are using TLS-encrypted SIP (port 5061), add or port 5061, though you will not be able to read the SIP content without the decryption keys.

If you are capturing on a busy network and only care about one phone, add the IP:

host 192.168.1.100 and (port 5060 or udp portrange 10000-20000)

Start the capture and reproduce the problem

Start the capture, make the call that demonstrates the problem, let it run for the duration of the issue, then stop the capture. Label your capture files clearly — bad-call-2026-04-03.pcapng is much more useful than capture7.pcapng six months later.

Finding calls in the capture

Telephony > VoIP Calls

This is the fastest way to find calls in a capture. Go to Telephony > VoIP Calls. Wireshark parses all SIP dialogs and shows each call with its start time, from/to, state, and duration. Select a call and click Flow Sequence to see the complete signaling ladder diagram — INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE.

This is the visual equivalent of reading Your First Call Flow: INVITE to BYE, but with your actual call data.

Display filters

If you prefer working with the packet list, these display filters isolate VoIP traffic:

All SIP traffic:

sip

SIP requests only (no responses):

sip.Request-Line

A specific call by Call-ID:

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

All RTP traffic:

rtp

SIP error responses (4xx, 5xx, 6xx):

sip.Status-Code >= 400

Registration traffic only:

sip.Method == "REGISTER"

Find the Call-ID from any SIP message in the call, then filter by that Call-ID to see the complete signaling for a single call without noise from other calls. For a full strategy on stripping out REGISTER, OPTIONS, and presence chatter before you hunt for the problem call, see Reading a SIP Trace Without Losing Your Mind.

Analyzing SIP signaling

The INVITE tells you the call setup story

Select the initial INVITE and expand the SIP headers. The critical fields:

From / To — who initiated the call and who it was directed to. Check for correct caller ID information.

Contact — the address where the phone wants to receive responses. If this contains a private IP address (192.168.x.x, 10.x.x.x) and the call is traversing NAT, this is a problem. The other side will try to send responses to a private IP it cannot reach. This is the classic SIP ALG and NAT traversal failure.

Via — the path the request has taken. Each proxy or device that handles the message adds a Via header. The rport and received parameters show the actual source IP and port as seen by the next hop, which is how NAT is detected.

SDP body — the media description. Look at the c= line (connection address — where to send RTP) and the m= line (media port and codec list). If the c= line contains a private IP and this is an external call, media will fail to reach the phone.

Response codes tell you what went wrong

If the call did not connect, the SIP response code tells you why. See SIP Response Codes: A Practical Reference for the full list. The most common failures:

• 401/407 — authentication required / proxy authentication required. Normal in registration flows, problematic if the phone cannot authenticate.
• 403 — forbidden. The provider is rejecting the call. Check credentials, IP whitelisting, or caller ID configuration.
• 404 — not found. The dialed number does not exist at the provider.
• 408 — request timeout. The other side did not respond. Network connectivity issue.
• 486 — busy here. The called party is on another call.
• 488 — not acceptable here. Codec negotiation failed — the two sides cannot agree on a common codec.
• 503 — service unavailable. The provider or server is overloaded or down.

Analyzing RTP media quality

Telephony > RTP > RTP Streams

This view shows every RTP stream in the capture. Each phone call typically has two streams — one in each direction. The columns you care about:

Packets — total packet count. A 60-second call at 50 packets per second should show approximately 3,000 packets per stream. Significantly fewer packets in one direction versus the other indicates one-way audio.

Lost — packets that never arrived, detected by gaps in the RTP sequence numbers. Under 1% is acceptable. Over 3% and the call quality is noticeably degraded.

Max Delta — the longest gap between consecutive packets. Normal is around 20 ms (for 50 pps codecs). Spikes over 100 ms indicate jitter events that will be audible.

Max Jitter — the computed interarrival jitter per RFC 3550. Under 30 ms is acceptable.

Mean Jitter — the average jitter. If this is low but max jitter is high, you have occasional spikes rather than consistently bad quality.

Select a stream and click Analyze for a detailed per-packet view including a jitter graph. The graph is invaluable — it shows you exactly when quality degraded during the call, which helps correlate with other network events.

Diagnosing one-way audio

Go to RTP Streams. Find the two streams for the problematic call (they will have the same IP pair but reversed source/destination). If one stream has packets and the other has zero or very few:

1. Check the SDP c= line in the INVITE and 200 OK. Is either side advertising a private IP address? If yes, the media is being sent to an unreachable address.
2. Check if SIP ALG rewrote the SDP. Compare the INVITE as sent by the phone (capture on the LAN) with the INVITE as seen on the WAN. If the c= address or m= port changed, ALG is mangling the media description.
3. Check your firewall rules. RTP uses high UDP ports (typically 10000-20000). If the firewall is blocking inbound UDP on those ports, return audio cannot reach the phone.

Diagnosing choppy audio

Both streams have packets, but the call sounds choppy or robotic:

1. Check the jitter graph. Consistent high jitter across the call points to a network quality issue — congestion, bufferbloat, or a bad network segment.
2. Check for periodic jitter spikes. Spikes every few seconds that align with other traffic patterns suggest bandwidth contention. Another device on the network may be sending bursts of data that crowd out the VoIP packets.
3. Check packet loss. Even 1-2% loss is audible. If loss is concentrated in bursts rather than evenly distributed, the audio will sound like brief dropouts rather than consistent degradation.

Skipping the manual work

Wireshark is powerful but time-consuming. If you need answers quickly — or if someone on your team does not know Wireshark — upload the capture file to our PCAP analyzer. It automatically extracts RTP streams, maps SIP dialogs, and calculates per-stream quality metrics. You get the same information as the Wireshark analysis above, presented in a structured report without manual filtering.

This is particularly useful when a customer or remote technician captures traffic and emails you a pcap file. Instead of walking them through Wireshark, send them to the analyzer and review the results together.

For the SIP signaling theory behind what you see in these captures, see Reading a SIP Trace: Practical Troubleshooting. For common SIP problems and their packet-level signatures, see Common SIP Problems and What They Look Like.