CallMeter Docs

Jitter Buffer Target Delay

Understand the jitter buffer target delay — the optimal buffering delay the adaptive algorithm is aiming to achieve.

The jitter buffer target delay is the delay, in milliseconds, that the adaptive buffer algorithm has calculated as the optimal buffering point. It represents where the buffer wants to be — the sweet spot between absorbing enough jitter to prevent gaps and keeping latency low enough for real-time conversation.

Think of it as the thermostat setting for your buffer. The current delay is the actual room temperature; the target delay is what the thermostat is set to. Comparing the two tells you whether the system is in equilibrium or still adjusting.

How It Works

Adaptive jitter buffers continuously analyze incoming packet timing to calculate the ideal buffer depth. The algorithm considers recent jitter patterns, packet loss history, and buffer underruns to determine a target that balances quality against latency.

The target delay changes over time as network conditions evolve:

  • When jitter increases, the target moves higher to accommodate wider timing variations.
  • When jitter decreases and stabilizes, the target gradually moves lower to reduce unnecessary latency.
  • After a burst of late packets, the target may temporarily spike upward as the algorithm protects against further disruption.

The current delay then tracks toward this target, growing or shrinking the buffer to match.

Adaptive vs fixed buffers

Fixed jitter buffers use a static delay that never changes. Adaptive buffers (used by modern systems) continuously adjust their target based on observed conditions. CallMeter measures both the target and current delay so you can see how well the adaptive algorithm is performing.

Why It Matters

The target delay is a window into the buffer's decision-making process. By comparing it with the current delay, you can diagnose buffer behavior:

RelationshipMeaning
Current matches targetBuffer is stable and well-adapted to conditions
Current below targetBuffer is catching up after recent changes, may have underruns
Current above targetBuffer is draining toward optimal, recently overcompensated
Target keeps risingNetwork conditions are worsening, jitter is increasing
Target stays high after jitter resolvesBuffer algorithm may be slow to recover, adding unnecessary latency

For SIP testing, the target delay trend over the duration of a test reveals how your infrastructure's network behavior evolves under load. A steadily rising target during a ramp-up phase confirms that increased traffic is degrading packet timing.

Common Scenarios

ScenarioTarget BehaviorWhat to Investigate
Stable call, good networkLow and steady (10-30ms)Nothing — this is ideal
Gradual congestionSlowly increasingGrowing traffic or bandwidth saturation
Intermittent jitter spikesJumps up, slowly recoversWiFi interference, competing traffic bursts
Consistently highStays above 100msPersistent jitter source on the network path
OscillatingSwings between low and highUnstable network conditions, routing flaps

How to Interpret It

  1. Compare with current delay — If they track closely, the buffer is adapting successfully. A persistent gap means the buffer is struggling to reach its target.
  2. Correlate with average jitter — Target delay should roughly correspond to the observed jitter. If target delay is much higher than jitter, the algorithm may be overshooting.
  3. Watch the trend during load tests — Plot target delay over time. The point where it starts climbing often corresponds to the moment your infrastructure begins to struggle under load.
  4. Compare across endpoints — If some endpoints have high targets and others do not, the issue is likely path-specific rather than systemic.
  • Current Delay — The actual buffering delay being applied right now
  • Average Jitter — The jitter measurement that drives target calculation
  • Late Packets — Packets arriving after deadline, which cause the target to increase
  • Packet Losses — Packets declared lost by the buffer, another factor in target adjustment

On this page