RTP Late Packets — VoIP Network Metric
RTP packets arriving after their network playout deadline — distinct from jitter buffer discards, exposing path delay spikes on SIP and WebRTC calls.
RTP Late Packets
| Property | Value |
|---|---|
| Key | late_packets |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Receive |
What It Measures
RTP Late Packets counts packets that arrived after their playout deadline at the network sequence level — distinct from jitter buffer late arrivals. Where jitter buffer late packets are detected at the playout stage (packets that arrived too late for the buffer to use), RTP late packets are detected at the network tracking stage by comparing actual arrival timing against expected inter-packet intervals derived from RTP timestamps.
A packet is counted as late when its arrival timestamp deviates from the expected arrival time by more than a configurable threshold, based on the sequence number gap and the RTP timestamp progression.
Why It Matters
RTP late packets and jitter buffer late packets measure delay at different layers — and they tell different stories:
- RTP late packets (this metric) — A network-level observation. The packet took longer to traverse the network path than expected based on the sender's clock. This is a pure network delay problem, independent of how the receiver configured its jitter buffer.
- Jitter buffer late packets — A receiver configuration observation. The packet arrived outside the window the jitter buffer was configured to accept. Increasing the buffer size may eliminate jitter buffer late packets without affecting RTP late packets.
When both metrics are elevated simultaneously, the root cause is network delay variation too large for any reasonable jitter buffer to accommodate. When only jitter buffer late packets are elevated but RTP late packets are low, the buffer is undersized for an otherwise acceptable network.
For SIP trunk qualification, RTP late packets reveal the worst-case delay spikes on a path — the ones that exceed not just the jitter buffer but the theoretical playout deadline. These spikes are the direct precursor to audible dropouts even on calls with acceptable average jitter.
Carriers who submit SLA reports based on average delay statistics can be hiding pathological tail latency. A path with 20ms average jitter may deliver 1% of packets with 300ms+ delay — enough to cause audible dropouts. RTP late packets surfaces this tail behavior that averages obscure.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 0 | No network-level late arrivals |
| Warning | 1 – 10 | Occasional delay spikes, monitor for increase |
| Critical | Above 10 | Systemic delay variation, audio quality impact |
How to Fix It
- Distinguish from jitter buffer late packets. If RTP late packets are near zero but jitter buffer late packets are elevated, increase the jitter buffer depth first — the network path itself may be acceptable.
- Look for delay spikes, not averages. Correlate late packet timing with call timeline events. Spikes that coincide with specific timestamps (top of the minute, quarter-hour boundaries) suggest scheduled processes on network devices.
- Check QoS consistency end-to-end. DSCP markings applied at the sender may be stripped or downgraded at an intermediate hop, exposing RTP packets to general-traffic queueing.
- Identify asymmetric paths. RTP late packets on one direction but not the other indicates an asymmetric routing or QoS configuration. Trace both paths independently.
- Enable priority queuing. Even with correct DSCP markings, ensure all intermediate devices support and respect priority queuing for voice traffic.
Related Metrics
- Jitter — Average delay variation; RTP late packets captures the tail that jitter averages hide
- Out-of-Order Packets — Often co-occurs with late packets when reordering is the delay source
- Max Packet Spacing — Peak inter-packet spacing; captures the same delay spikes from a spacing perspective
- Packet Loss Rate — Packets late enough miss the jitter buffer and are counted as lost