Choppy audio, robotic voices, clipping, and dropped words — these are the symptoms of VoIP packet loss. RTP packet loss in VoIP means audio data is being dropped before it arrives. Unlike one-way audio, both parties can hear each other but quality is degraded. Here's how to measure acceptable packet loss thresholds, find the cause, and fix it.
RTP (Real-time Transport Protocol) carries the actual audio in a VoIP call as a continuous stream of small UDP packets, typically 20ms of audio per packet. When packets are lost in transit — dropped by a router, queued too long, or arriving out of order — the receiving endpoint has gaps in the audio stream.
The codec's packet loss concealment (PLC) algorithm tries to fill these gaps, but it can only do so effectively for short bursts of loss. Above 1-2% sustained loss, most codecs produce audible artifacts. Above 5% loss, calls become difficult to understand.
RTP uses UDP, not TCP, so there are no retransmissions. Lost packets are gone. The network must deliver them reliably in the first place.
| Packet Loss | MOS Impact | User Experience | Status |
|---|---|---|---|
| 0% | None | Perfect audio | Excellent |
| < 0.5% | Minimal | Imperceptible to most users | Good |
| 0.5–1% | Slight | Occasional very brief clips | Acceptable |
| 1–3% | Moderate | Noticeable choppy audio | Degraded |
| 3–5% | Significant | Frequent gaps, hard to follow | Poor |
| > 5% | Severe | Nearly unintelligible | Unacceptable |
For VoIP calls, acceptable packet loss is generally below 1%. Most users notice degradation above 1-2%, and calls become difficult to understand above 5%. These thresholds assume random (uncorrelated) loss. Bursty loss — where multiple consecutive packets are dropped — is much more damaging than the same percentage of random loss, because PLC can't conceal long gaps effectively.
RTCP Receiver Reports (RR) are sent periodically alongside the RTP stream and contain the cumulative fraction of packets lost. Look for RTCP RR packets in your capture and check the fraction lost field (0–255, where 255 = 100% loss) and cumulative packets lost.
RTP packets include a sequence number that increments by 1 for each packet. In a PCAP, filter on the RTP stream and look for gaps in sequence numbers. A jump from sequence 1000 to 1003 means packets 1001 and 1002 were lost.
Most PBX systems (Asterisk, FreeSWITCH, Kamailio) and SBCs log per-call RTP statistics including packet loss counts. Check your call detail records or enable verbose RTP logging to see live statistics.
In Wireshark, use rtp as a display filter. Then use Telephony → RTP → RTP Streams to see all detected streams with summary statistics including packet loss percentage.
Select an RTP stream and use Telephony → RTP → Stream Analysis. Wireshark plots each packet and marks sequence number gaps in red. This shows you exactly when loss occurred and whether it's random or bursty.
RTCP RR reports are sent every few seconds. Check if the fraction lost increases consistently (ongoing network problem) or spikes at specific times (burst loss from a congestion event). Timestamp the spikes against other network events.
High jitter (> 30ms) alongside packet loss suggests network congestion. Jitter without loss suggests buffering issues. Loss without jitter suggests physical layer problems (Wi-Fi drops, hardware errors) or policer/shaper enforcement.
If loss is only in one direction, the problem is on the sending side's network path. If loss is in both directions, the problem is likely at a shared network point — your internet connection, a shared WAN link, or a congested core router.
Implement QoS: Mark RTP packets DSCP EF (46) at the PBX or SBC. Configure your routers and switches to honor DSCP markings and give EF traffic strict priority queuing. On Cisco equipment, use LLQ (Low Latency Queuing). This is the single highest-impact fix for loss caused by congestion.
Separate voice and data VLANs: Put VoIP devices on a dedicated VLAN with its own traffic policies. This prevents a large data transfer from competing with active calls on the same switch port or uplink.
Increase WAN bandwidth or upgrade SLA: If loss is consistently on the WAN link, you've outgrown your capacity. Calculate your concurrent call count × codec bandwidth (G.711 = ~87kbps per call including headers) and ensure you have headroom for burst traffic.
Fix Wi-Fi: Use 5GHz band, select a non-overlapping channel (1, 6, or 11 for 2.4GHz; any non-overlapping for 5GHz), ensure adequate AP coverage so devices don't roam unnecessarily, and consider dedicated VoIP-optimized APs for high-density environments.
Switch to Opus: If you can't fix the network, Opus with FEC enabled can recover from up to 10% random packet loss with minimal perceptible degradation. Configure your PBX to prefer Opus and enable inband FEC.
Tune the jitter buffer: For most deployments, an adaptive jitter buffer with a target delay of 40–60ms and a maximum of 150ms is appropriate. Increase the maximum if you're seeing frequent late-packet discards on high-jitter networks.
Jitter is variation in packet arrival timing. Packets are sent at regular intervals (every 20ms) but arrive at irregular intervals due to variable queuing delays in the network. A jitter buffer absorbs this variation at the cost of added latency.
Packet loss is when packets don't arrive at all. The jitter buffer can't help with true loss — it can only discard late packets, which appears as loss from the codec's perspective.
High jitter without packet loss: tune your jitter buffer deeper. Packet loss without high jitter: network congestion or physical layer issues. Both together: severely congested or unreliable network path — QoS and capacity are the fixes.
Upload your PCAP to SIPSymposium. The analyzer extracts RTP statistics, reads RTCP receiver reports, identifies loss patterns, calculates estimated MOS scores, and gives you specific recommendations based on your call data.
Acceptable packet loss for VoIP is below 1%. Under 0.5% is imperceptible to most users. Between 1–3% users notice choppy audio. Above 5% calls become nearly unintelligible. See the full threshold table in section 2 above.
The most common causes are network congestion on a shared link, missing QoS (DSCP EF marking), Wi-Fi interference, ISP or WAN issues, PBX CPU overload, and a jitter buffer that's too shallow and discarding late packets.
Measure from RTCP Receiver Reports in Wireshark — look for the fraction lost field. Or count gaps in RTP sequence numbers. Most PBX systems log per-call RTP statistics including loss counts in CDRs.
Implement QoS with DSCP EF (46) marking, separate voice onto a dedicated VLAN, fix Wi-Fi by switching to 5GHz, upgrade WAN capacity, or switch to Opus with FEC enabled — it recovers from up to 10% random loss with minimal quality impact.
Upload your PCAP to SIPSymposium. The analyzer measures packet loss per stream, identifies burst vs random loss patterns, reads RTCP statistics, and tells you exactly where in the network path the loss is occurring.