There is a point in every VoIP troubleshooting process where the logs stop being useful and you need to see what is actually happening on the wire. That is when you pull a packet capture.
A packet capture (pcap) records every packet flowing through a network interface. For VoIP, that means you can see the exact SIP messages that set up and tear down calls, the exact RTP packets that carry audio, and the precise timing of every packet arrival. It is the closest thing to ground truth you can get when diagnosing call quality problems.
But a pcap file full of thousands of packets is only useful if you know what to look for. This is a practical guide to extracting meaningful diagnostic information from packet captures of VoIP calls.
When you need a capture (and when you don't)
Not every call quality problem requires a packet capture. If calls are choppy during afternoon hours and your bandwidth monitoring shows the internet link saturating at 3pm every day, you have your answer without opening Wireshark. If phones are not ringing and the SIP registration status shows unregistered, start with the registration problem.
Packet captures become necessary when:
The symptoms do not match an obvious cause. One-way audio, intermittent drops, or choppy audio with no apparent network congestion all warrant a closer look at what the packets are actually doing.
You need to prove where a problem is occurring. If your VoIP provider says the issue is on your network and you say the issue is on theirs, a capture at your network edge showing clean outbound packets and damaged inbound packets settles the argument.
SIP behavior is unexpected. Calls failing for unclear reasons, unexpected response codes, or features not working as configured all benefit from seeing the actual SIP messages exchanged.
Where to capture
Placement matters. A capture taken at the wrong point in the network path may not contain the information you need.
At the endpoint. Some VoIP phones and softphones can generate their own packet captures. This is ideal because it shows exactly what the phone sends and receives, including any issues introduced by the local network. Polycom, Yealink, and most enterprise phones have a built-in pcap feature accessible through their web interface.
At the switch (mirror port). If the endpoint cannot capture, configure a SPAN or mirror port on your managed switch to copy traffic from the phone's port to a monitoring port where your laptop runs Wireshark. This captures everything the phone sends and receives without affecting the phone's performance.
At the router or firewall. Captures here show traffic as it enters and leaves your network. This is useful for proving whether packets are clean when they leave your LAN (making any downstream quality issue your ISP's problem) but you miss issues that occur between the phone and the router.
On both sides. For the most complete picture, capture simultaneously at the endpoint and at the network edge. Comparing the two captures shows you exactly where packets are being lost, delayed, or reordered.
SIP analysis: the call setup story
Before you look at audio quality, check that the call set up correctly. Open the capture in Wireshark and use the Telephony → SIP Flows or Telephony → VoIP Calls dialog to see a visual call flow diagram.
What to look for:
The INVITE and its response. A healthy call starts with an INVITE, receives a 100 Trying, then a 180 Ringing, then a 200 OK, and the caller sends an ACK. If you are seeing unusual response codes, the SIP message anatomy and the response code tell you what went wrong and at which point in the dialog.
SDP content. The SDP bodies in the INVITE and 200 OK tell you what codec was negotiated, what IP addresses and ports are being used for media, and whether both sides agree on the media parameters. Mismatches here cause one-way audio and codec problems. Check that the IP addresses in the SDP are routable and correct — NAT issues often manifest as private IP addresses appearing in SDP where public addresses should be.
Re-INVITEs. Mid-call re-INVITEs can change codec, put calls on hold, or trigger other changes. An unexpected re-INVITE or a rejected re-INVITE can explain sudden quality changes or call drops.
BYE timing. If calls are dropping after a set time, look at what sends the BYE and when. A BYE from the far end's proxy after exactly 30 or 60 minutes often indicates a session timer. A BYE that does not appear at all (the call just stops) suggests a network interruption.
For a deeper walkthrough of SIP message analysis, see reading a SIP trace and first call flow: INVITE to BYE.
RTP analysis: the audio quality evidence
This is where packet captures earn their keep for quality troubleshooting. The RTP stream is the actual audio, and its characteristics tell you exactly what the listener experienced.
In Wireshark, go to Telephony → RTP → RTP Streams to see all RTP streams in the capture. Select a stream and click Analyze to get the detailed statistics.
Packet loss
Wireshark calculates packet loss by looking at RTP sequence numbers. Each RTP packet has a sequential number. If sequence number 1000 is followed by 1002, packet 1001 was lost. Wireshark reports both the total lost packets and the loss percentage.
What the loss pattern tells you:
Uniform, steady loss (roughly the same percentage throughout the call) suggests a consistent network problem. A congested link, a misconfigured QoS policy, or a path with consistent errors.
Burst loss (periods of no loss punctuated by clusters of consecutive lost packets) points to momentary congestion events. A large file transfer or backup saturating the link for a few seconds, a routing reconvergence, or a buffer overflow on an intermediate device.
Loss in one direction only indicates an asymmetric problem. The path from A to B is fine but the path from B to A is impaired. This is common when the two directions of a call take different network paths, which is normal on the internet.
Any loss above about 1% is typically audible. At 3-5%, calls become noticeably degraded. At 10% or more, calls are unusable.
Jitter
Wireshark calculates inter-arrival jitter for each RTP stream. This is the variation in the time between consecutive packet arrivals compared to the expected interval.
For a standard 20ms ptime (packet time), packets should arrive roughly every 20 milliseconds. Wireshark graphs the actual arrival intervals so you can see where jitter spikes occur.
Jitter that stays under 20-30ms is generally handled by the phone's jitter buffer without audible impact. Jitter spikes above 50ms start to exceed typical buffer sizes, causing the buffer to either drop late packets (creating loss) or introduce additional delay.
The jitter graph over time is more useful than the average jitter number. A call with 8ms average jitter sounds clean. A call with 8ms average jitter that includes two 200ms spikes does not, even though the average looks fine.
Timing gaps
Look for gaps in the RTP stream — periods where no packets arrived. A gap of several hundred milliseconds or longer in the middle of active speech suggests a network interruption, a device failure, or a routing change. These gaps are distinct from silence suppression, where the sender intentionally stops sending packets during silence. Silence suppression gaps happen between speech bursts. Network gaps happen during speech.
Wireshark marks gaps in the RTP stream analysis. Correlate gap timing with any SIP signaling events (re-INVITEs, UPDATE messages) to determine whether the gap was intentional or a network problem.
Payload type consistency
Each RTP packet carries a payload type number that identifies the codec. For G.711 u-law, this is payload type 0. For G.711 a-law, it is 8. For dynamic codecs like Opus, the payload type is assigned during SDP negotiation.
If the payload type changes mid-stream without a corresponding re-INVITE and new SDP negotiation, something is wrong. A codec mismatch mid-call causes the receiver to try to decode audio with the wrong codec, producing noise or silence.
Common patterns and what they mean
Clean SIP, bad RTP. The call set up perfectly but the audio is terrible. This is a network quality problem, not a VoIP configuration problem. Focus on the RTP stream analysis to quantify the loss, jitter, and timing issues, then trace the network path to find the impaired segment.
Packets fine at the switch, damaged at the router. Comparing captures from two points shows packets being lost between them. You have an internal network issue — possibly a misconfigured QoS policy, an overloaded uplink, or a failing cable.
Packets fine leaving your network, damaged on return. The outbound RTP stream is clean in your capture but the inbound stream shows loss and jitter. The problem is on the internet path between your ISP and the remote end. This is where you take the evidence to your ISP or VoIP provider.
Consistent 30-second call drops. SIP shows no BYE message and RTP simply stops. This is almost always a NAT timeout or firewall state table issue. The stateful firewall stops seeing traffic for long enough that it drops the session, and subsequent packets are blocked.
One-way audio from the start. SDP analysis usually reveals the cause immediately: a private IP address where a public one should be, a port that is unreachable, or a SIP ALG rewriting the SDP incorrectly.
Practical tips
Filter early. A busy network generates enormous captures. Use Wireshark display filters to focus on the call you care about. Filter by the phone's IP address (ip.addr == 10.0.1.50) or by SIP (sip) and RTP (rtp) protocols to cut the noise.
Capture in both directions. RTP is bidirectional. The caller sends a stream and receives a stream. Analyze both. A problem that only affects one direction tells you something different than a problem that affects both.
Save the capture. Pcap files are small relative to their diagnostic value. Save them with a naming convention that includes the date, the affected extension, and a brief description of the symptom. When you need to compare today's problem to last month's problem, you will be glad you kept the files.
Correlate with call quality reports. If your VoIP platform provides call quality metrics (jitter, loss, MOS estimates), compare them to what the packet capture shows. Discrepancies between platform-reported metrics and pcap-observed metrics tell you something about where the platform is measuring and what it might be missing.
Packet captures are not the first troubleshooting step and they should not be the last resort either. They sit in the middle of a competent troubleshooting process: after you have ruled out the obvious, before you start guessing. When the question is "what is actually happening on the wire," a pcap is the definitive answer. If you have a capture file and want a quick summary, the PCAP analyzer extracts SIP signaling and RTP quality metrics directly in the browser.
Frequently Asked Questions
Where should I capture packets to troubleshoot VoIP quality?+
Capture as close to the endpoint experiencing the problem as possible. If the phone sounds bad, capture on the switch port the phone is connected to (using a mirror/SPAN port) or on the phone itself if it supports packet capture. Capturing at the router only shows you what the traffic looks like after it has traversed your LAN, which means you miss any issues introduced by the internal network. See our Wireshark VoIP guide for capture setup details.
How many packets do I need to capture to diagnose a VoIP problem?+
Capture the entire call, from the first SIP INVITE to the final BYE. For intermittent problems, you may need to capture over a longer period and wait for the issue to recur. A typical 5-minute G.711 call generates roughly 30,000 RTP packets in each direction, which is a manageable capture file size.
Can I use Wireshark to measure MOS score from a packet capture?+
Wireshark can estimate MOS based on the jitter and loss it observes in the RTP stream, but this is an approximation. It uses the E-model algorithm to compute an estimated score from network metrics. It does not perform actual audio quality analysis. The estimate is useful for identifying clearly problematic streams but should not be treated as a precise MOS measurement. You can also upload the capture to the PCAP analyzer for automated quality scoring.
What does it mean when I see RTP packets out of order in a capture?+
Out-of-order packets mean that packets are arriving in a different sequence than they were sent. Small amounts of reordering (a packet or two arriving one position late) are handled by the jitter buffer and may not be audible. Significant reordering suggests a network path issue, often caused by load balancing across multiple paths or routing instability.
Share
Want to know when we publish new articles? Sign up for updates