Three network impairments account for almost every complaint about VoIP audio, and they damage a call in different ways. Latency, the one-way delay from mouth to ear, does not distort audio at all: it breaks the turn-taking rhythm of conversation, so people interrupt each other. Jitter, the variation in packet arrival times, is harmless in itself and becomes damaging only through the buffer that absorbs it, which either adds delay or discards packets. Packet loss removes speech outright, and how bad it sounds depends far more on the pattern of loss and the codec in use than on the percentage.
The important part, and the part most troubleshooting misses, is that these three are coupled. A buffer set to absorb more jitter adds delay. A buffer set to keep delay low discards more packets and looks like loss. The engineering job is not to minimise any one of them but to find the trade that the conversation can carry.
Quick reference
| Impairment | What it is | How it is heard | Where it is fixed |
|---|---|---|---|
| Latency | One-way delay, mouth to ear | Talk-over, awkward pauses, people repeating themselves | Path selection, codec and packet size, buffer sizing |
| Jitter | Variation in the delay of successive packets | Nothing directly. The buffer converts it into delay or into gaps | Queue management, buffer policy, removing contention |
| Packet loss | Packets that never arrive, plus packets discarded for arriving late | Clipped words, robotic artefacts, dropouts | Congestion relief, route change, codec robustness |
| Burstiness | Whether losses are isolated or clustered | Isolated losses are often inaudible. Clusters are not | The same causes as loss, but it must be measured separately |
The three impairments are not independent
Start with the trade-off, because everything else follows from it.
A receiver cannot play out audio the instant it arrives, because arrivals are uneven. It holds packets briefly in a jitter buffer and releases them on a fixed schedule. A large buffer absorbs more variation and loses fewer packets, at the cost of delay. A small buffer keeps delay low and discards anything that arrives after its play-out slot. ITU-T Recommendation G.114 is explicit about the consequence: if a packet’s delivery time exceeds the buffer, it arrives too late for its play-out time and is discarded, and the speech it carried is lost to the decoder just as if the network had dropped it.
This is why “we reduced jitter buffer size to cut latency” and “we increased jitter buffer size to stop dropouts” are both true statements made by people who have moved the same problem sideways.
Where delay actually comes from
Delay is not one number produced by one device. It is the sum of small contributions along a one-way path, and each end of the call has its own budget. Delay is cumulative and one-directional, and only the total is heard.
The codec contributes first. G.114 gives the arithmetic for IP systems directly: the delay attributable to codec processing is between two and three times the frame size plus the look-ahead time, and when several frames are packed into one packet it becomes at least (N + 1) times the frame size plus look-ahead, where N is the number of frames per packet. That single formula explains a large share of real-world delay differences. A codec with 0.125 ms frames contributes a fraction of a millisecond. A codec with a 10 ms frame and 5 ms look-ahead contributes roughly 25 to 35 ms with one frame per packet. A 30 ms frame codec contributes between about 68 and 98 ms before a packet has even left the building.
Propagation is the next block, and it is the one nobody can optimise away. G.114’s planning values put optical fibre at about 5 microseconds per kilometre, so a 5,000 km path costs roughly 25 ms in each direction on the fibre alone. A geostationary satellite hop costs about 260 ms of propagation between earth stations, which is why a single satellite leg dominates every other contribution combined.
Queueing is the block that varies. Serialisation on a slow access link, contention with other traffic, and buffering in intermediate devices add delay that is invisible when the link is idle and substantial when it is busy. This is why call quality complaints cluster at the times when someone starts a large upload.
The jitter buffer is last, and G.114 offers a planning rule worth remembering: assume a de-jitter buffer adds about half of its peak delay to the mean network delay. Its example is a buffer designed to compensate for 50 ms of delay variation, which adds about 25 ms on average.
What the standards actually say about delay thresholds
Two numbers get quoted constantly and both are usually quoted loosely.
G.114 recommends not exceeding 400 ms of one-way delay for general network planning, and states that below 150 ms mouth-to-ear most applications, speech and non-speech, experience essentially transparent interactivity. It also says something that gets dropped from summaries: these are not the tool for assessing quality. The recommendation directs planners to the E-model in ITU-T G.107 for the combined effect of delay with other impairments, because delay in isolation is not how a call is experienced.
The E-model itself is more forgiving than the folklore at low delay values and stricter about context. Its delay impairment factor is zero while absolute delay stays at or below a minimum perceivable delay parameter, whose default value is 100 ms. Above that, impairment grows. Crucially, G.107 specifies that carrier-grade and enterprise-grade telephony must be assessed with the default delay sensitivity settings, and that the more relaxed settings apply only where the use case is known to be less interactive.
For scale, G.114’s own worked guidance suggests intra-regional VoIP paths of 5,000 km or less are likely to land under 150 ms mouth-to-ear, that a 10,000 km path lands around 225 ms, and that even a worst-case 27,500 km terrestrial path comes in just over 300 ms, assuming terminals that contribute about 80 ms in total with 20 ms packets and robust concealment. If a domestic call is measuring 300 ms, the distance is not the explanation.
Jitter is not delay, and the buffer is where it is paid for
Jitter is variation, not lateness. A path with a constant 200 ms delay has no jitter and sounds fine apart from the awkward turn-taking. A path averaging 40 ms with swings between 10 and 120 ms has excellent average delay and will sound terrible.
The number people quote comes from RFC 3550, which defines interarrival jitter as the smoothed mean deviation of the difference in packet spacing between sender and receiver. For packets i and j, D is the difference in relative transit time, and the reported value is updated for each packet as J(i) = J(i-1) + (|D(i-1,i)| – J(i-1))/16. The specification requires implementations to use this exact formula so that reports from different vendors can be compared at all.
Three consequences of that definition matter in practice, and all three are stated in the RFC itself.
The gain of 1/16 makes the value a smoothed estimate. A single severe excursion is diluted across subsequent packets, so a report can look calm while a listener heard a distinct break.
The value is a snapshot sampled when a report is issued, and RFC 3550 says plainly that it is not intended to be taken quantitatively. It is meant for comparison across reports over time or across receivers at the same time.
Loss and jitter measure different things. The RFC frames it neatly: loss tracks persistent congestion, jitter tracks transient congestion, and the jitter measure may indicate congestion before it turns into loss. Rising jitter with no loss is an early warning, not a false alarm.
How jitter turns into loss
A packet that arrives after its play-out deadline is useless. The decoder needed it at a specific instant, that instant has passed, and the audio for that interval has already been produced by concealment or silence. The buffer discards it, and it never reaches the decoder.
Now the part that causes weeks of misdiagnosis. RFC 3550 defines the cumulative loss count as packets expected less packets received, where received includes any that are late or duplicated, so packets that arrive late are not counted as lost. The reported loss figure is a statement about the network, not about the decoder. A call can be full of audible gaps while the loss counter sits at zero, because every gap came from a discard rather than a drop.
This is the single most useful thing to know when a customer reports choppy audio and every network statistic looks clean. The measurement you want is discard rate at the receiving buffer, which lives in endpoint or session border controller statistics rather than in basic RTCP reception reports.
Why the same loss percentage sounds different
Two calls, both reporting 2 per cent packet loss, can be a mild annoyance and a failed conversation. The difference is the pattern and the codec, and the standards model this explicitly rather than treating loss as a single number.
G.107 folds loss into the effective equipment impairment factor with the relationship Ie-eff = Ie + (95 – Ie) x Ppl / (Ppl / BurstR + Bpl). Ie is the impairment of the codec with no loss at all, Bpl is that codec’s packet-loss robustness factor, Ppl is the loss probability, and BurstR is the burst ratio, which equals 1 when loss is random and rises above 1 when losses cluster. G.107 notes that the model’s predictions for burst ratios above 2 are only valid when loss stays below 2 per cent, which is itself an admission that heavily bursty loss is hard to model and worse to listen to.
Two design conclusions follow.
A robust codec genuinely buys tolerance, because Bpl is codec-specific and sits in the denominator. G.107 adds a condition that engineers routinely ignore: the robustness value must match the codec, the packet size and the concealment implementation in use. Packing more frames per packet means each lost packet takes more speech with it, so it changes the effective robustness as well as the delay.
Reporting an average loss percentage without a burstiness measure hides the thing that determines how the call sounded. Four isolated losses across twenty packets are usually concealed. Four consecutive losses are a missing syllable.
What packet loss concealment can and cannot do
Concealment estimates the missing audio from what came before. For a single lost frame in steady speech, this works well enough that most listeners notice nothing. For consecutive losses, the estimate drifts away from the real signal, which is where the robotic or watery artefacts come from, and eventually the decoder gives up and outputs silence or comfort noise.
Some codecs go further and carry a compact copy of the previous frame’s information, so a receiver that loses one packet can reconstruct it from the next. That converts an audible gap into a small quality dip at the cost of extra bitrate, which is a reasonable trade on a lossy access network and a waste on a clean one.
What concealment cannot do is recover conversation. It hides audio damage, not delay, and it does nothing for the interruptions that latency causes.
How quality models combine the three
The E-model produces a single rating factor R from the sum of impairments: R = Ro – Is – Id – Ie-eff + A, where Id carries all delay-related impairments including talker echo, and Ie-eff carries codec and loss impairments. With every parameter at its default the model yields R = 93.2.
G.107 maps that rating to user satisfaction bands: at 90 or above users are very satisfied, at 80 satisfied, at 70 some users are dissatisfied, at 60 many are, and at 50 nearly all are. The same annex converts R into an estimated MOS.
The reason to know this is not to calculate it by hand. It is to understand that these bands are additive across impairments, so a call at 180 ms with a robust codec and no loss can rate better than a call at 90 ms with a low-bitrate codec and clustered loss. Judging a route by any single metric misranks routes.
Why MOS numbers from different tools disagree
MOS in monitoring dashboards is almost never a mean opinion score. It is a model output, usually the E-model estimate derived from measured loss, delay and jitter.
G.107 says directly that its estimates of customer opinion are made for transmission planning purposes and not for predicting actual customer opinion, and notes that the ITU-T recommends no model for the latter. Two dashboards will disagree whenever they assume different codec impairment values, different concealment behaviour, different burstiness handling, or whether echo and delay sensitivity were included at all.
Treat modelled MOS as a comparison tool inside one measurement system and over time. It is a poor basis for a contractual argument between two parties using different tools.
What to measure, and what each measurement misses
| Measurement | What it tells you | What it hides |
|---|---|---|
| Round-trip time from ping | Rough path health | One-way delay, which can be asymmetric, and the codec and buffer contributions that make up most of a voice budget |
| RTCP fraction lost and cumulative lost | Packets the network failed to deliver | Packets discarded by the jitter buffer for arriving late |
| RTCP interarrival jitter | A smoothed, comparative indicator of transient congestion | Individual excursions, and any absolute judgement of severity |
| Jitter buffer discard rate | The gaps the decoder actually experienced | Nothing about why the packets were late |
| Burst and gap statistics | Whether losses clustered | Little on its own without loss rate alongside |
| Modelled MOS or R factor | A combined comparison over time | Its own assumptions, which differ between tools |
Two practical notes. RTCP reports are deliberately infrequent, with a recommended minimum interval of five seconds and a control bandwidth of about 5 per cent of the session, so a report is a coarse summary rather than a trace. And because the jitter calculation uses the sender’s timestamp, variation introduced before transmission, such as packets covering different durations, shows up as jitter too. RFC 3550 accepts this on the grounds that the receiver’s buffer has to absorb it either way.
Common causes, ranked by how often they explain a complaint
Contention on the last mile. A shared upstream link with no prioritisation puts voice behind bulk traffic. The signature is jitter and loss that correlate with time of day rather than with destination.
Wireless access. Retransmissions and roaming events produce bursty loss and jitter excursions that no core network change will fix.
Overloaded customer equipment. Firewalls and session border controllers doing deep inspection at capacity add variable delay to the packets they forward.
A long or indirect route. Real when it is real, and less common than assumed. Check propagation arithmetic before blaming geography: about 5 microseconds per kilometre sets a floor that most domestic complaints are nowhere near.
Codec and packetisation choices. Large frames and multiple frames per packet save bandwidth and cost delay and loss sensitivity at the same time.
Buffer policy at the endpoint. Aggressive low-latency settings produce discards that appear nowhere in network statistics.
What actually fixes each problem
For delay: shorten what you control. Fewer frames per packet, a codec with a shorter frame where quality permits, and no unnecessary media relays. Delay added by an extra hairpin through a distant media server is often larger than the entire propagation budget.
For jitter: stop the variation rather than absorbing it. Prioritise voice on congested links, keep queue depths short on the access path, and remove the devices that buffer aggressively. Enlarging the jitter buffer is a mitigation, and it is paid for in delay.
For loss: find out first whether it is loss or discard. Network loss points at congestion or a faulty path. Discard points at jitter or buffer policy. The remedies do not overlap.
For burstiness: treat it as a separate finding. Clustered loss usually means a specific event, such as a wireless retransmission, a route flap or a queue emptying, rather than a steady background rate.
Where didlogic fits
Voice quality is decided across a chain, and no single party owns all of it. didlogic operates the carrier layer: SIP trunking and international voice termination, where route selection, interconnect quality and the codec offered on the trunk are set. Those choices bound the delay a call inherits before it reaches the destination network, and they determine how much loss the path introduces.
What remains with the customer is equally decisive: the access link, the local network, the endpoint or platform, the jitter buffer policy and the codec preferences configured on the customer side. A codec chosen for bandwidth economy on a lossy access link will produce complaints that no carrier route change can resolve, which is why codec selection belongs in the same conversation as routing.
When reporting a quality problem to any carrier, the useful package is the same: call identifiers, direction, timestamps, destination, and separated loss and discard figures. That is what allows two parties to look at the same call from both sides and reach the same conclusion.
FAQs
What is an acceptable latency for VoIP?
ITU-T G.114 recommends not exceeding 400 ms one-way for general network planning and notes that below 150 ms mouth-to-ear most applications feel essentially transparent. Anything in between is a judgement about the conversation type, which is why G.107 models delay sensitivity separately.
Is jitter or packet loss worse?
Neither, in isolation. Jitter matters only through what the buffer does with it, and loss matters mainly through its pattern. A call with 1 per cent clustered loss usually sounds worse than one with 2 per cent scattered loss.
Why does my monitoring show no packet loss when users hear dropouts?
Because RTCP counts late arrivals as received, so packets discarded by the jitter buffer never appear as loss. Look for a discard or late-packet counter on the receiving device.
How much packet loss is acceptable?
There is no universal figure, which is the point of the E-model’s treatment: the impairment depends on the codec’s robustness, the packet size, the concealment implementation and the burst ratio, not on the percentage alone.
Does more bandwidth fix voice quality?
Rarely on its own. A voice stream needs very little bandwidth. What it needs is bounded queueing delay, which is a scheduling question rather than a capacity question.
Can a jitter buffer be too large?
Yes. It converts variation into delay, and delay damages conversation even when the audio is perfect. Adaptive buffers manage the trade dynamically, though G.114 notes they introduce their own transitional delay changes when they resize.
Is MOS measured or calculated?
In monitoring tools it is almost always calculated from a model. G.107 is explicit that its estimates exist for transmission planning and not for predicting real customer opinion.
Continue learning
