Max Packet Spacing
Maximum time between consecutive RTP packets in a 2-second window — detects burst delays, network stalls, and the worst-case gaps in media delivery.
Max Packet Spacing
| Property | Value |
|---|---|
| Key | max_packet_spacing |
| Unit | Milliseconds (ms) |
| Type | Gauge |
| Direction | Receive |
What It Measures
Max Packet Spacing records the largest time gap between two consecutive RTP packets within a 2-second measurement window. For a G.711 stream with 20ms packetization, consecutive packets should arrive approximately 20ms apart. If the maximum spacing in a window is 200ms, it means at some point during those 2 seconds, there was a 200ms gap where no packets arrived.
Think of it like tracking the longest pause between cars on a highway. Even if traffic is flowing smoothly on average, one 30-second gap means someone experienced a long wait.
Why It Matters
Max packet spacing reveals the worst-case delivery behavior that average metrics conceal:
- Burst delay detection — A 150ms spacing in a 20ms stream means the receiver had no new media for 150ms. The jitter buffer must compensate for this or the user hears a gap.
- Jitter buffer sizing — The jitter buffer must be at least as large as the maximum expected spacing. If max spacing exceeds the buffer, packets arriving after the gap will be too late for playout.
- Network stall identification — Brief network stalls (routing convergence, firewall state rebuild, WiFi contention) show up clearly in max spacing even when average jitter looks fine.
- SLA evidence — Some SLAs define maximum acceptable packet delay. Max spacing provides direct evidence of whether the worst-case delay meets requirements.
How CallMeter Measures It
CallMeter measures the arrival time of every RTP packet and calculates the inter-packet spacing. Within each 2-second measurement window, the maximum spacing value is recorded. This captures the single worst-case gap in packet delivery for that period.
Thresholds
Expected max spacing depends on the codec's packetization interval:
| Codec | Ptime | Expected Max Spacing |
|---|---|---|
| G.711 (20ms) | 20ms | 20-25ms (normal) |
| Opus (20ms) | 20ms | 20-25ms (normal) |
| Video | varies | Frame interval dependent |
| Deviation | Interpretation |
|---|---|
| Within 25% of ptime | Normal network variation |
| 2-5x ptime | Network hiccup or brief congestion |
| Above 5x ptime | Significant stall event |
What Causes High Max Spacing
- Network congestion bursts — Brief queue overflow events that delay multiple packets, then release them in a burst.
- WiFi contention — Extended contention windows on busy channels delay transmission until the channel is free.
- Route convergence — During routing table updates, packets may be delayed or buffered while the new path is established.
- Firewall inspection delays — Deep packet inspection that occasionally takes longer for certain packets.
- Sender-side issues — The remote endpoint may pause transmission briefly due to CPU contention, garbage collection, or encoder stalls.
How to Fix It
- Compare with average spacing. If max spacing is high but Avg Packet Spacing is normal, you have occasional burst events rather than chronic delay.
- Check the timeline. Identify when max spacing spikes occur. Periodic spikes suggest scheduled events (backup jobs, cron tasks) consuming bandwidth.
- Increase jitter buffer. If max spacing regularly exceeds the jitter buffer target, the buffer needs to be larger — but this adds playout delay.
- Investigate the spike source. A max spacing of 500ms in a 20ms stream is a 25-packet gap. Correlate with Sequence Gaps to see if packets were lost or just delayed.
Related Metrics
- Min Packet Spacing — The other extreme; shows packet bunching
- Avg Packet Spacing — The typical spacing for comparison
- Jitter — Smoothed average of spacing variation
- Sequence Gaps — Whether high spacing caused by delay or loss
Sequence Number Jumps
Large discontinuities in RTP sequence numbers — indicates network path changes, stream switches, or SSRC transitions.
Min Packet Spacing
Minimum time between consecutive RTP packets in a 2-second window — reveals packet bunching caused by network buffering or sender-side batching.