Wireshark Basics for VoIP: Verifying SIP and RTP Flows

You just deployed a new VoIP system, configured the PBX, and pointed your phones to the server. Everything looks green on the dashboard. But when you pick up the handset, the audio is choppy, or worse, one-way. How do you know if the problem is the phone, the network, or the configuration? You don't guess. You look at the packets.

Wireshark is the industry standard for this job. It’s free, it runs on Windows, macOS, and Linux, and it has been decoding voice traffic since the early 2000s. If you can see the SIP signaling and the RTP media streams, you can diagnose almost any issue in seconds. This guide walks you through the exact steps to verify that your calls are setting up correctly and that the audio quality is acceptable.

Why Wireshark Is Essential for VoIP Verification

Voice over IP isn’t like traditional telephony where a dedicated wire carries the signal. It’s data. Specifically, it’s two distinct types of data traveling over the same network: control signals and actual audio. When things break, they rarely break in obvious ways. A call might connect but drop after ten seconds. The audio might be robotic. One party might hear silence.

To fix these issues, you need to separate the problem into its components. Wireshark lets you do exactly that by capturing raw network traffic. Unlike monitoring tools that only show aggregate statistics, Wireshark shows you every single packet. This granularity is crucial because VoIP failures often stem from tiny timing errors or misconfigured headers that high-level dashboards miss entirely. By analyzing the interaction between the Session Initiation Protocol (SIP) messages and the Real-time Transport Protocol (RTP) streams, you gain complete visibility into the lifecycle of a call.

Setting Up Your Capture Environment

Before you open Wireshark, you need to ensure you’re capturing the right traffic. Most VoIP issues are local to the endpoint or the immediate network segment. Here’s how to set up a clean capture:

1. Select the correct interface: Open Wireshark and choose the network adapter connected to your VoIP device or PBX. If you are using a laptop with both Wi-Fi and Ethernet, make sure you pick the active one.
2. Start the capture: Click the blue shark fin icon. Let it run while you make a test call. Keep the call short-about 10-15 seconds is usually enough to capture setup, media flow, and teardown.
3. Stop the capture: Once the call ends, hit the red stop button.

A common pitfall here is missing the traffic due to switch port mirroring configurations. If you are capturing on a router or a PC not directly connected to the phone, ensure that your network switch is configured to mirror the port where the VoIP traffic flows. Otherwise, you’ll see nothing but background noise.

Verifying SIP Signaling Flow

The first phase of any VoIP call is signaling. This is the handshake that establishes the connection. In Wireshark, we isolate this using display filters. Type sip in the filter bar at the top. This hides all non-SIP traffic, leaving you with just the control messages.

Look for the standard sequence of events. A successful call setup typically follows this pattern:

• INVITE: The caller sends an INVITE message to the callee (or the PBX).
• 100 Trying: The receiving end acknowledges receipt of the request.
• 180 Ringing: The callee’s phone starts ringing.
• 200 OK: The callee answers the call.
• ACK: The caller confirms the answer, completing the three-way handshake.

If you see a 4xx or 5xx status code instead of a 200 OK, you have a signaling error. For example, a 403 Forbidden often means authentication failed, while a 404 Not Found suggests the dialed number doesn’t exist or routing is broken. To visualize this entire conversation, right-click on any SIP packet, select Follow, and then SIP Call. Wireshark will generate a ladder diagram showing the exact timeline of messages exchanged between the endpoints. This visual aid makes spotting out-of-order messages or missing ACKs incredibly easy.

Analyzing RTP Media Streams

Once the call is established, the actual audio moves via RTP. Wireshark automatically correlates SIP sessions with their corresponding RTP streams if the SDP (Session Description Protocol) information in the SIP messages is valid. To check the media quality, go to the menu bar and select Telephony > RTP > Show All Streams.

This window lists every RTP stream detected in your capture. Pay close attention to the following metrics:

Jitter refers to the variation in packet arrival time. Since VoIP relies on real-time delivery, inconsistent timing causes gaps or overlaps in audio playback. Packet loss occurs when data packets fail to reach their destination, resulting in clicks, pops, or dropped words. If you see high jitter or loss, the issue is likely network congestion, QoS misconfiguration, or wireless interference.

Listening to the Audio with RTP Player

Numbers are helpful, but hearing is believing. Wireshark includes a built-in tool called the RTP Player that lets you listen to captured audio streams directly. From the RTP Streams window, select a stream and click Play Streams.

A new window opens with a waveform view. Press play. If you hear clear speech, your media path is working. If you hear silence, check if the stream is actually carrying data (look at the packet count). If you hear robotic or distorted audio, compare the codec used in the capture against what your devices support. Common codecs include G.711 (PCMU/PCMA), which is uncompressed and reliable, and G.729 or Opus, which are compressed and bandwidth-efficient but more sensitive to packet loss.

You can also export the audio as a WAV file to analyze it further in external software. This is particularly useful when you need to prove to a vendor or client that the audio degradation originated within the network, not at the endpoint.

Troubleshooting Common Pitfalls

Even experienced engineers run into issues with Wireshark captures. Here are three frequent problems and how to solve them:

• RTP Not Detected: Sometimes Wireshark fails to link RTP packets to a SIP session. This happens if the SDP body is encrypted or malformed. Try filtering for rtp manually. If you see UDP traffic but no RTP label, right-click a UDP packet, select Decode As, and force it to decode as RTP.
• One-Way Audio: Check the source and destination IP addresses in the RTP streams. If both directions show packets flowing but one side hears nothing, the issue is often NAT traversal. Ensure your SIP ALG (Application Layer Gateway) is disabled on your firewall/router, as it frequently mangles SIP headers and breaks media negotiation.
• Noisy Captures: If your capture is flooded with unrelated traffic, use combined filters. For example, sip || rtp shows only signaling and media. To focus on a specific device, add an IP filter: sip && ip.addr == 192.168.1.50.

Automating Checks with tshark

If you manage a large fleet of VoIP devices, manual inspection doesn’t scale. Enter tshark, the command-line version of Wireshark. You can script checks for jitter and packet loss across multiple PCAP files.

For instance, running tshark -r capture.pcap -q -z rtp,streams outputs a text summary of all RTP streams, including SSRC IDs, packet counts, and jitter values. This allows you to integrate VoIP health checks into CI/CD pipelines or automated monitoring scripts, alerting you before users complain about poor call quality.

Frequently Asked Questions