When a VoIP call drops, echoes, or goes silent, you don’t need to guess what’s wrong. You can see it-down to the last packet. Wireshark doesn’t tell you what happened; it shows you exactly what happened. And for VoIP, that’s everything.
Why Wireshark Is the Only Tool That Tells the Full Story
Most VoIP monitoring tools give you dashboards: jitter here, latency there, maybe a red alert when things go bad. But they don’t show you why. Wireshark does. It captures every single packet that moves across your network, then decodes it in plain language. If a SIP INVITE fails, you see the exact error code. If audio cuts out, you see which packets got lost-and where. It’s free. It’s open source. And as of 2025, it’s still the only tool that can reconstruct a full VoIP call from raw network traffic. Companies like Cisco, Microsoft, and AT&T use it internally. Not because they can’t afford commercial tools, but because nothing else gives them this level of control.How SIP and RTP Work Together (And Why You Need Both)
VoIP calls are split into two parts: signaling and media. SIP (Session Initiation Protocol) is the phone call’s director. It sets up the call, negotiates codecs, and tears it down. It runs over TCP or UDP, usually on port 5060. When you dial a number, SIP handles the handshake: "Can you talk?", "Sure, I’m ready", "Let’s start now." RTP (Real-time Transport Protocol) is the voice itself. It carries the actual audio-your words, your pauses, your "uh-huh"-as small packets over UDP. These packets fly at 20ms intervals, 50 times a second. If even one gets delayed or lost, you hear a glitch. Here’s the catch: Wireshark can’t decode RTP unless it sees the SIP signaling first. SIP tells Wireshark which IP and port to expect the audio on, and what codec is being used. Without SIP, you’re just looking at random UDP traffic.Essential Wireshark Filters for SIP Analysis
You won’t find what you need by scrolling through thousands of packets. Filters are your lifeline. Here are the five most critical SIP filters:- sip - Shows all SIP traffic. Use this first to see if signaling is happening at all.
- sip.Status-Code >= 400 - Filters out failed calls. Anything 400 or higher means the call didn’t go through. 404 = user not found. 486 = busy. 503 = server overload.
- sip.CSeq.method == "INVITE" - Shows only call setup attempts. If you’re missing calls, this tells you if they’re even being sent.
- sip.Request-Line contains "REGISTER" - Helps track device registration. If phones keep dropping off, this shows if they’re failing to authenticate.
- sip.Contains("SDP") - Pulls up the Session Description Protocol messages. These tell you what audio codec is being used-G.711, G.729, Opus-and whether both sides agreed on it.
Mastering RTP Filters and Stream Reconstruction
Once SIP confirms a call is active, you need to find the RTP stream. Here’s how:- rtp - Shows all RTP packets. Simple, but noisy.
- rtp && udp.port == 4000 - Replace 4000 with the actual port from the SIP SDP. This narrows it down to one specific voice stream.
- rtp.seq == 1234 - Look for missing sequence numbers. If you see 1230, 1231, 1233, 1234-you lost packet 1232. That’s your audio glitch.
- Packet loss percentage (e.g., 0.8%)
- Jitter (e.g., 12.4ms)
- Delay (e.g., 148ms one-way)
- Estimated MOS score (e.g., 4.2 - good quality)
Common VoIP Problems-and How Wireshark Fixes Them
One-way audio: You hear the other person, but they don’t hear you. This is almost always a firewall or NAT issue. Check the RTP stream in both directions. If one side has packets going out but none coming back, the firewall is blocking inbound UDP. Call drops during transfer: SIP REFER messages handle call transfers. Filter for sip.CSeq.method == "REFER". If the transfer fails, look for a 403 or 488 response. Often, the target device doesn’t support the codec being sent. Choppy audio: High jitter. Look at the Stream Analysis graph. If jitter spikes above 30ms, your network is congested. Check for background traffic-large file transfers, video calls, backups-on the same link. No audio at all: SIP might have succeeded, but RTP never started. Check the SDP in the SIP message. Is the media line set to "sendrecv"? Or is it "inactive"? If it’s inactive, the phone didn’t enable the audio stream.What Wireshark Can’t Do (And What to Use Instead)
Wireshark is a microscope, not a security camera. It’s perfect for forensic analysis after a problem occurs. But it doesn’t alert you in real time. If you need 24/7 monitoring with SMS alerts, use a commercial tool like PRTG or VoIP Monitor. It also can’t decrypt SRTP (Secure RTP). If your VoIP system uses encryption, you need the encryption key. Wireshark will show you encrypted packets as gibberish. There’s no workaround-unless you have the key, you’re blind. And it’s not user-friendly. If you’re new to networking, expect to spend 15-20 hours learning before you’re confident. YouTube tutorials help. So does the Wireshark User’s Guide. But don’t expect magic buttons.
Pro Tips from Real-World Use
- Always capture on the switch or router where VoIP traffic passes through-not just on the user’s PC. Local captures miss network-level issues.
- Use capture filters: udp port 5060 or udp portrange 10000-20000. This keeps your file size small and focused.
- Save your captures with clear names: Call_Failure_2025-04-12_SIP486.pcapng. You’ll thank yourself later.
- Use the Telephony > VoIP Calls menu. It lists every call in your capture with start/end times, duration, and status. Click one, and Wireshark highlights all related packets.
- For large captures (over 1GB), use a machine with 16GB RAM. Wireshark can handle it, but your laptop might struggle.
What’s Next for Wireshark and VoIP
WebRTC is changing VoIP. More calls are now coming from browsers, not phones. Wireshark 4.0+ handles WebRTC signaling and SRTP decryption better than ever. But encrypted traffic is growing fast-63% of enterprises now use SRTP, according to Gartner. The Wireshark team is working on automated MOS scoring and SRTP key import workflows. That’ll cut hours off troubleshooting. But for now, the core skills haven’t changed: know SIP, know RTP, know how to read the numbers.Final Thought: The Power of Seeing the Unseen
VoIP isn’t magic. It’s packets. And Wireshark lets you see them. You don’t need to be a network engineer to use it-you just need to be curious. When the next call drops, don’t call IT. Open Wireshark. Filter for SIP. Look for RTP. Find the missing packet. Fix the problem. That’s not just troubleshooting. That’s control.How do I filter SIP calls that failed in Wireshark?
Use the display filter sip.Status-Code >= 400. This shows all SIP responses with error codes 400 and above, including 404 (Not Found), 486 (Busy Here), and 503 (Service Unavailable). These indicate failed call attempts. You can then right-click any of these packets and select "Follow > SIP Stream" to see the full conversation leading to the failure.
Why can’t I hear the audio even though RTP packets are visible?
Wireshark can display RTP packets but cannot play audio unless the codec is supported and the stream is correctly reconstructed. First, check if the codec (like G.711 or G.729) is listed in the SIP SDP. Then, go to Telephony > RTP > Stream Analysis, select the stream, and click "Play". If no sound plays, the codec may be unsupported, the stream may be encrypted (SRTP), or the packet loss may be too high for reconstruction.
What’s the difference between SIP and RTP in VoIP?
SIP handles call setup and control-it’s the phone call’s director. It negotiates who’s calling, what codec to use, and when to end the call. RTP carries the actual voice data. Think of SIP as the phone line connecting two people, and RTP as the conversation happening over that line. Without SIP, Wireshark can’t know which UDP packets are voice. Without RTP, there’s no audio to analyze.
How do I find the correct RTP stream when there are many calls?
Use the Telephony > VoIP Calls menu. It lists every call in your capture with timestamps, duration, and status. Click any call, and Wireshark highlights all SIP and RTP packets related to that session. You can also use the SIP SDP (Session Description Protocol) to find the exact UDP port assigned for RTP-then filter with rtp && udp.port == [port].
Can Wireshark analyze encrypted VoIP calls (SRTP)?
Only if you provide the encryption key. SRTP encrypts the RTP payload, so Wireshark sees it as random data. To decrypt, go to Edit > Preferences > Protocols > SRTP and add the key and salt values from your VoIP system’s configuration. Without these, you’ll only see encrypted packets and cannot analyze audio quality or detect packet loss in the media stream.
What’s a good MOS score, and how does Wireshark calculate it?
A MOS (Mean Opinion Score) of 4.0 or higher is considered good voice quality. Wireshark estimates MOS using a formula based on packet loss, jitter, and one-way delay. For example, 0.5% packet loss and 20ms jitter might give you a MOS of 4.3. Values below 3.5 indicate poor quality. Wireshark’s calculation is based on ITU-T G.107 recommendations and is widely accepted in enterprise VoIP environments.
Do I need to capture traffic on the VoIP phone itself?
No. Capturing on the phone only shows traffic from that device. To see network-level problems like routing delays, firewall blocks, or congestion, capture on a switch port, router, or network TAP that sees all VoIP traffic. This gives you the full picture-both directions of the call, and any intermediate hops that might be causing issues.
Why does my Wireshark capture lag or freeze during large VoIP sessions?
Wireshark uses system resources to decode packets in real time. Large captures (over 1GB) or high packet rates (over 10,000 packets per second) can overwhelm older systems. Use a machine with at least 8GB RAM (16GB recommended), close other apps, and use capture filters to reduce data volume. For long-term analysis, save the capture and open it later on a more powerful machine.
Bob Buthune
5 Dec 2025 at 22:52Man, I spent three days last month troubleshooting a one-way audio issue with a client's VoIP system. Wireshark saved my sanity. I was looking at jitter, packet loss, everything looked fine-until I checked the SDP in the SIP INVITE. The phone was sending 'inactive' instead of 'sendrecv'. No wonder the other side heard nothing. I almost called the vendor until I remembered: it's never the hardware, it's always the config. Saved the filter as 'SIP_SDP_Inactive' and now I use it on every call. Also, 🤯🤯🤯 if you're not using the Telephony > VoIP Calls menu, you're doing it wrong. It's like a magic wand for call reconstruction. And yes, I cried when I first saw the MOS score pop up. Not because I'm emotional-because it was accurate. 🥲