Out-of-Order Packets

What It Measures

Out-of-Order Packets counts the number of RTP packets that arrive at the endpoint in a different order than they were sent. Packet 101 should arrive before packet 102, but if 102 arrives first, packet 101 is counted as out-of-order when it eventually shows up.

In a well-behaved network, packets follow the same path and arrive in the order they were sent. When packets take different routes — or encounter different queuing delays — they can arrive out of sequence. The receiver must then reorder them before playback.

Why It Matters

Out-of-order packets create real problems for media quality:

• Audio glitches — The jitter buffer can compensate for some reordering, but packets that arrive too late to be reordered are effectively lost. This creates brief audio gaps or clicks.
• Video artifacts — Video frames depend on packet order for decoding. Out-of-order packets can corrupt frame assembly, causing visual glitches until the next keyframe.
• Jitter buffer pressure — The jitter buffer must be sized to accommodate not just timing variation but also reordering depth. More reordering means larger buffers and higher playout delay.
• False loss detection — Some loss detection mechanisms may briefly report a packet as lost before it arrives out of order, creating misleading intermediate metrics.

How CallMeter Measures It

CallMeter tracks the expected RTP sequence number for each incoming stream. When a packet arrives with a sequence number lower than the current expected value (indicating it arrived after a later packet), it is counted as out-of-order. The counter increments throughout the call.

Thresholds

What Causes Out-of-Order Packets

• Multipath routing (ECMP) — Different packets in the same flow get routed through different paths with different latencies, causing them to arrive out of order.
• QoS reclassification — If some packets get classified into different QoS queues mid-stream (due to DSCP remarking or policy changes), they experience different queuing delays.
• Network path changes — BGP reconvergence or OSPF recalculation during a call can temporarily cause packets to take different routes.
• WiFi retransmission — WiFi MAC-layer retransmissions can delay individual packets, causing them to arrive after subsequent packets.
• Load balancer issues — Some load balancers do not maintain per-flow affinity for UDP, distributing packets from the same RTP stream across different backend paths.

How to Fix It

1. Ensure per-flow ECMP hashing. If using multipath routing, configure hash-based load balancing on the 5-tuple (source IP, dest IP, source port, dest port, protocol) to keep all packets in a flow on the same path.
2. Check QoS consistency. Verify that DSCP markings are preserved end-to-end and all devices classify RTP traffic the same way.
3. Use wired connections. WiFi retransmission is a common source of reordering. Use wired connections for SIP infrastructure.
4. Verify load balancer configuration. Ensure UDP session affinity is configured on any load balancers in the media path.
5. Monitor path stability. Correlate out-of-order spikes with network events like routing changes or failovers.

Related Metrics

• Jitter — Reordering contributes to measured jitter
• Duplicate Packets — Often co-occurs in multipath scenarios
• Sequence Gaps — Large gaps may include reordered packets initially counted as lost
• Max Packet Spacing — Reordered packets cause irregular spacing