Jitter is the variation in the arrival times of packets travelling through an IP network. In voice communications, it is one of the three core measurements, alongside latency and packet loss, that determine whether a call sounds clean or breaks up, and it is the metric that most directly causes audible artefacts in real-time speech.
Where latency tells you how long a packet takes to get from sender to receiver, jitter tells you how consistent that delay is. A network with 80 ms of latency and zero jitter feels stable. A network with the same average 80 ms but with packets arriving anywhere between 20 ms and 140 ms will sound rough, the receiver simply can’t reassemble the audio stream into smooth speech without intervening, and that intervention always comes at a cost.
How jitter works
Voice traffic on an IP network is carried as a stream of small RTP packets, typically one every 20 ms. The receiver expects them to arrive at the same cadence so it can play them back in real time. In practice, packets travel through routers, switches, firewalls, and sometimes wireless segments, and at every hop they may queue, get reordered, or be deprioritised behind other traffic. The result is that the spacing between packets at the receiver is rarely as regular as it was at the sender.
To smooth this out, every voice endpoint runs a jitter buffer, a small playout queue that holds incoming packets briefly before releasing them at a steady pace. If the buffer is sized to hold, say, 40 ms of audio, it can absorb up to about 40 ms of jitter without anyone noticing. Beyond that, packets arriving too late are effectively lost, because the buffer has already moved on. Packets arriving too early just wait, but waiting means added end-to-end delay.
Jitter buffers can be fixed or adaptive. A fixed buffer is simple but either wastes latency on a quiet network or drops packets on a noisy one. An adaptive buffer grows when the network gets jittery and shrinks when it calms down, trading latency against loss in real time. The standard measurement of jitter itself is defined in IETF RFC 3550 – interarrival jitter is a smoothed estimate of the variance in packet spacing, reported back through RTCP messages.
Jitter in telecom networks
In commercial telecom networks, jitter is one of the headline numbers on every voice quality SLA. Carriers running SIP trunks, VoLTE traffic, hosted PBX services, and over-the-top voice applications all need to keep jitter inside well-understood thresholds, broadly, under 30 ms of mean jitter for good perceived quality, with the exact figure depending on the codec and the receiver’s buffer strategy.
Jitter shows up everywhere in a typical carrier network. Access links, especially residential broadband and mobile wireless, are the most variable. Aggregation networks usually behave well unless they’re congested. Peering points between carriers can introduce surprises when a route flips or one side reroutes for capacity reasons. Session border controllers, media gateways, and softswitches all maintain their own jitter buffers and policy controls, and the way those interact across a multi-hop call can amplify or smooth jitter in non-obvious ways.
Operators monitor jitter continuously to spot patterns. A slow rise across a particular peering link points to capacity exhaustion. A sudden spike on a single trunk often points to a misconfigured QoS policy. Persistent jitter on calls involving a specific access network can drive engineering decisions about codec selection or media routing. None of those problems show up clearly without per-stream, packet-level visibility, which is why jitter measurement is a foundational part of any serious voice quality monitoring deployment.
Jitter in air traffic control
In air traffic control, jitter takes on heightened significance because the operational consequences of degraded audio are not a frustrated customer hanging up, they are a missed instruction in a safety-critical exchange. Modern ATC voice systems built around EUROCAE ED-137 carry pilot-controller and controller-controller communications over IP, and they are subject to exactly the same jitter dynamics as any other VoIP system, even when the underlying transport is a managed, carrier-grade network with generous headroom.
The trade-off between jitter buffer size and end-to-end latency is sharper in ATC than in commercial telecoms. A controller and a pilot in an active exchange need the conversation to feel immediate; long buffer-driven delays interfere with the rhythm of clearance and read-back, and they can cause overlapping transmissions when one party hears the other late and assumes the channel is free. ED-137 sets out specific expectations for how jitter buffers should behave, but the deployed reality varies, and a jitter buffer that performs well on a synthetic test can still produce audible artefacts under bursty live traffic.
This is exactly the territory voice quality monitoring for air traffic control is built for. Continuous packet-level measurement of jitter on every stream air-ground, ground-ground, recorder feed, exposes the difference between a network that meets ED-137 on paper and one that delivers consistently intelligible voice in operations. Trending jitter over time, correlating it with PTT events, and breaking it down by sector or endpoint turns a single number into something an engineering team can act on, before it becomes a controller complaint or a flight-safety report.
Mitigation and trade-offs
The instinctive response to jitter is to increase the receiver’s jitter buffer, but in real-time voice that comes at the cost of latency, and in a half-duplex ATC context that latency is operationally expensive. A more durable approach is to attack jitter at its sources: provisioning enough capacity on the voice-carrying segments, applying QoS marking (DSCP EF for voice) consistently along the path, isolating real-time traffic from bulk transfers, and engineering route stability so media doesn’t bounce between paths mid-call.
Codec choice matters too. Lower-bitrate codecs produce smaller, more frequent packets, which gives the network more chances to introduce jitter but also makes adaptive buffering work better. Packet loss concealment algorithms partially mask the effects of late arrivals, but they are a last line of defence, not a fix.
The deeper point is that jitter is rarely a single problem with a single cause. It is the visible symptom of how a network is behaving moment to moment, and treating it well requires being able to see it in detail, per call, per segment, per minute, rather than just reading a daily average off a dashboard.