Latency, Jitter, and Packet Loss: The Details

VoIP From the Ground Up: Part 8 of 10

We introduced the three enemies of voice quality in Part 4. This post goes deeper. If you have been following the series, you now understand what a network is, how packets move, and why voice is uniquely sensitive to network conditions. This is where we get into the specific numbers and mechanics that separate a good call from a bad one.

Latency in depth

Latency is the total time it takes for audio to travel from your mouth to the other person's ear. It is the sum of several components, and understanding what contributes to it helps explain why some latency is fixable and some is not.

Where latency comes from

Codec processing delay. Encoding your voice into compressed digital data takes time. Most modern codecs introduce between 1 and 30 milliseconds of delay depending on the algorithm and the frame size used. The G.711 codec, which does minimal compression, has almost no codec delay. More aggressive codecs like G.729 require more processing time.

Packetization delay. The codec produces audio in chunks, typically 10 to 30 milliseconds per chunk. A 20 millisecond packetization interval means the codec has to wait 20 milliseconds to collect enough audio to fill one packet before it can send anything. You can reduce this by using smaller intervals, but smaller packets mean more packets per second, which increases overhead on the network.

Queuing delay. At every router and switch along the path, packets may have to wait in a queue before being forwarded. If the device is busy processing other traffic, your voice packet sits in a buffer until it is its turn. During periods of congestion, queuing delay can spike dramatically and unpredictably.

Transmission delay. The time it takes to physically push the packet onto the wire. On modern high-speed connections this is negligible, but on slower links (some older broadband connections, for example) it can add up, especially for larger packets.

Propagation delay. The speed-of-light limitation. Even on fiber, signals take roughly 5 milliseconds to travel 1,000 kilometers. This component is fixed by geography and cannot be reduced without physically moving the endpoints closer together.

Jitter buffer delay. The receiving device deliberately holds packets in a buffer to smooth out arrival time variations. This intentional delay typically adds between 20 and 60 milliseconds, depending on how the buffer is configured and how much jitter it needs to absorb.

Adding it all up

For a call between two locations in the same city, total one-way latency might be 30 to 60 milliseconds under good conditions. Between opposite coasts of the United States, 60 to 120 milliseconds is typical. International calls can easily exceed 150 to 200 milliseconds.

The International Telecommunication Union's transmission-planning recommendation, ITU-T G.114, cites 150 milliseconds one-way as the boundary below which most applications are essentially unaffected. Between roughly 150 and 300 milliseconds one-way, the delay becomes increasingly noticeable and starts disrupting natural conversation flow. Above 300 milliseconds, real-time conversation is seriously impaired.

It is worth being precise about what these numbers are. They are planning guidance grounded in decades of research into how humans perceive conversational timing, not a point at which audio suddenly fails. Quality degrades gradually as delay grows, and the conversational effect depends on the total mouth-to-ear delay and on how well echo is controlled -- a call with poor echo cancellation feels worse at a given delay than one without. The 150 millisecond figure is roughly where the gap between speaking and hearing a response becomes long enough that both speakers begin to misread conversational cues and talk over each other.

Jitter in depth

Jitter is the variation in packet arrival times. If latency were perfectly consistent, every packet arriving exactly 20 milliseconds after the last, there would be no jitter. In reality, network conditions change from moment to moment, and each packet's journey is slightly different.

Measuring jitter

In practice, VoIP endpoints report the interarrival jitter statistic defined in RFC 3550, the RTP specification: a running, exponentially smoothed estimate of how much packet spacing deviates from the expected interval. Intuitively, if packets are supposed to arrive every 20 milliseconds, and the actual gaps are 18, 22, 19, 25, 17, and 31 milliseconds, the jitter estimate tracks the typical amount by which those gaps differ from 20 milliseconds. Because it is a statistical estimate, a single reported number summarizes behavior over time rather than capturing every individual spike; extensions like RTCP XR (RFC 3611) add detail such as how many packets arrived too late to play.

A few milliseconds of jitter is normal and harmless. The jitter buffer at the receiving end absorbs it easily. Problems start when jitter exceeds the capacity of the buffer.

The jitter buffer trade-off

The jitter buffer is one of the most important and least understood components in VoIP. It works by adding intentional delay to create a cushion for absorbing timing variations.

Imagine packets arriving at irregular intervals. Without a buffer, the receiving device would try to play each packet the instant it arrived. The result would be audio that speeds up and slows down as packet spacing varies. With a buffer, the device collects packets and plays them at a steady rate, smoothing out the irregularities.

The trade-off is direct. A larger buffer can absorb more jitter, but it adds more latency. A 60 millisecond buffer adds 60 milliseconds to the total delay. A smaller buffer reduces delay but cannot handle as much variation. When a packet arrives too late to make it into the buffer's playback window, it is discarded as if it were lost.

This means that high jitter effectively becomes packet loss. A packet that arrives 80 milliseconds late on a system with a 40 millisecond jitter buffer is thrown away. The audio it carried is gone. From the listener's perspective, there is no difference between a packet that was genuinely lost in the network and one that arrived too late to be useful.

Most VoIP systems use adaptive jitter buffers that automatically adjust their size based on observed network conditions. When the network is stable, the buffer shrinks to minimize delay. When jitter increases, the buffer grows to absorb it. This helps, but it is a reactive system. Sudden spikes in jitter can overwhelm the buffer before it has time to adapt.

Target jitter values

There is no standards-mandated jitter threshold -- what a given level of jitter does to a call depends on the codec, the endpoint's buffer behavior, and how much delay budget is left after everything else. But as operating targets, the following bands are widely used: for consistently good voice quality, aim to keep average jitter below 20 milliseconds. Jitter between 20 and 50 milliseconds is usually manageable with a well-configured buffer, at the cost of noticeable added latency. Above 50 milliseconds, call quality tends to degrade even with aggressive buffering, because the buffer has to add so much delay that the conversation starts to feel laggy -- the damage arrives as buffer delay and late-packet discard rather than as "jitter" directly.

Packet loss in depth

Packet loss is the percentage of packets that are sent but never arrive. For VoIP, which uses a delivery method that does not resend lost packets, any lost packet represents a permanent gap in the audio.

What packet loss sounds like

The effect of packet loss on audio depends on how much is lost, how it is distributed, and what the codec can do about it -- the concealment and any forward error correction built into the codec, and the packetization interval, all shift where the pain starts. One thing that does not change with the codec: a lost 20 millisecond packet removes 20 milliseconds of audio whether its payload was G.711 or G.729. What differs is how convincingly the decoder can paper over the hole. The percentage bands below are rough guides, not fixed thresholds.

Random, low-level loss (below 1%). Individual packets go missing at irregular intervals. Modern codecs conceal this with packet loss concealment, which extrapolates the missing audio from what has already been received -- typically by extending the pitch and energy of the preceding packets. (A real-time decoder generally cannot borrow from future audio to fill a gap without deliberately adding delay, which is why concealment quality falls off quickly as gaps get longer.) Most listeners will not notice anything wrong at this level.

Random, moderate loss (1 to 3%). Concealment algorithms start to struggle. Listeners hear occasional brief dropouts, words that clip at the beginning or end, or subtle artifacts that sound slightly robotic. The call is usable but clearly impaired.

Random, high loss (3 to 5%). Frequent and obvious gaps. Words and sometimes entire phrases go missing. The listener has to ask the speaker to repeat themselves regularly. Business communication becomes frustrating and unreliable.

Burst loss. Instead of losing individual packets at random, you lose multiple consecutive packets at once. Even a short burst (50 to 100 milliseconds) creates a gap that concealment cannot fill. The listener hears a clear dropout, as if someone briefly muted the microphone. Burst loss is often caused by network equipment that drops its entire buffer when overwhelmed, rather than dropping packets randomly.

The relationship between the three

Latency, jitter, and packet loss are not independent problems. They interact in ways that make quality worse than any single metric would suggest.

High jitter causes effective packet loss through the jitter buffer mechanism described above. High latency combined with even moderate jitter makes conversations significantly harder than either problem alone, because the increased delay amplifies the awkwardness of timing mismatches. Packet loss on top of already-high latency is particularly destructive because the codec's concealment algorithms have less margin to work with when the overall timing is already tight.

This is why evaluating VoIP quality requires looking at all three metrics together, not in isolation -- and why our VoIP quality test measures all three simultaneously. A call path with 80 milliseconds latency, 10 milliseconds jitter, and 0.5% loss will sound fine. A path with 120 milliseconds latency, 35 milliseconds jitter, and 2% loss will be miserable, not because any single number is catastrophic, but because the combination exceeds what the system can compensate for.

The MOS score

The industry's standard way of collapsing all of these metrics into a single quality rating is the Mean Opinion Score. We have a dedicated post on this topic, MOS Scores Explained, if you want the full breakdown. The short version is that MOS rates call quality on a scale from 1 (unusable) to 5 (excellent), and computational models like the ITU-T G.107 E-model can estimate it from measured network conditions without needing a panel of human listeners. One mechanical detail worth knowing: the E-model's inputs are delay and loss, not jitter directly. Jitter enters the calculation only after being converted into its real-world consequences -- the extra delay the jitter buffer adds, and the packets discarded for arriving too late, which count as loss. That is exactly the buffer mechanism described above, formalized into a planning model.

What comes next

Now that we understand the metrics, the next post covers the most powerful tool available for protecting voice quality on the network you control: Quality of Service. This is where we move from diagnosing problems to actively preventing them.

This is Part 8 of the VoIP From the Ground Up series. Part 9: Quality of Service, Telling Your Network What Matters covers how to configure your network to prioritize voice traffic over everything else.