Jitter, latency and packet loss: diagnosing bad call quality

“The line was bad” covers at least three unrelated faults with three unrelated causes. Separating them is most of the diagnosis, and each has a recognisable sound.

Latency: the conversation gets awkward

One-way delay does not distort the audio at all. It breaks the turn-taking — both parties start speaking at once, then both stop, then both start again. People describe this as a bad line but what they mean is that the conversation was hard work.

ITU-T G.114 puts the comfortable ceiling for one-way delay at around 150 ms, with up to 400 ms tolerable for some applications. Above 150 ms most people notice; above 250 ms they complain.

Latency accumulates from distance, from every device in the path, from the codec and packetization interval, and — most commonly in the cases that surprise people — from a jitter buffer set generously to cover a jittery link. A fix for jitter can create a latency complaint.

Jitter: words break up

Jitter is variation in packet arrival times. Voice is a constant-rate stream; if packets arrive unevenly, the receiver has to hold them in a buffer and play them out smoothly. When jitter exceeds what the buffer covers, packets arrive too late to use and are discarded — so jitter presents as loss, with a choppy, syllable-dropping quality.

Under about 30 ms is normally invisible. Above that, the buffer either grows (adding latency) or discards (adding loss). This is why jitter, latency and loss cannot be diagnosed independently: the buffer trades between them.

The usual cause is contention — a link carrying voice and bulk traffic with no queuing policy. A backup job, a large upload or a software deployment produces exactly this signature, and it is often reproducible at the same time each day.

Packet loss: clipped and hollow

Lost packets produce gaps. Modern codecs conceal small amounts by interpolating, which is why 1% loss is usually inaudible and 5% is obviously broken — concealment covers isolated packets and cannot cover bursts.

Burst loss is much worse than the same total spread evenly, so an average loss figure can look acceptable while calls sound terrible. Look at the distribution, not the mean.

Common causes, roughly in order of how often they turn out to be the answer: a saturated uplink, a duplex mismatch or failing port on the LAN, wireless coverage at the edge of range, and an over-eager firewall or SBC dropping RTP it has decided is idle.

Getting the measurement rather than the impression

Most SIP endpoints and PBXs record RTCP statistics per call — jitter, loss, and round-trip time. That is the data to look at first, because it is per call and already collected.

What makes it useful is asking the right questions of it:

• Is it one direction only?One-way problems point at a specific link or a NAT/firewall path, not at the internet generally.
• Is it one site, one subnet, one switch?The narrowest common factor is usually the cause.
• Is it time-correlated?A daily pattern is contention. A random pattern is more often a faulty device.
• Is it internal calls too?If internal calls are clean and external ones are not, the LAN is exonerated in one step.

What actually fixes each

• LatencyRemove hops, choose a closer media path, reduce packetization, and check whether an inflated jitter buffer is the real cause.
• JitterQueue voice ahead of bulk traffic and enforce it; find the traffic it is competing with.
• LossFind the saturated link or the failing port. Wireless voice needs coverage designed for it, not coverage that happens to reach.

Two things are worth saying plainly: prioritization only works where you control the queue, so it helps on your own links and does nothing across the public internet; and marking traffic DSCP EF achieves nothing if no device in the path acts on the marking.

Measure continuously, not during an incident

The hardest quality problems are intermittent, and an investigation that starts when someone complains has no history to compare against. Recording per-call RTCP statistics continuously turns “calls were bad yesterday afternoon” into a graph with a cause on it.

AcmaPBX keeps per-call quality statistics as history rather than as a live view only, which is what makes an intermittent complaint diagnosable after the fact instead of only while it is happening.