Jitter Buffer RTX Requests

Understand jitter buffer RTX requests — retransmission requests sent by the buffer to recover missing packets before their playback deadline.

Jitter buffer RTX requests is a cumulative count of retransmission requests the jitter buffer has sent to recover missing packets. When the buffer detects a gap in the incoming packet sequence, it can proactively request the sender to retransmit the missing packet before the playback deadline passes.

Think of it as calling the courier to re-deliver a package before the deadline. If the re-delivery arrives in time, no one notices the original was lost.

How It Works

When the jitter buffer detects a sequence number gap in incoming RTP packets, it evaluates whether there is enough time to request and receive a retransmission before the playback deadline for that packet. If there is, it sends an RTX (retransmission) request to the sender.

The RTX mechanism operates on a tight timeline:

Buffer detects a missing sequence number
Buffer sends an RTX request (via NACK or a dedicated RTX channel)
Sender retransmits the packet from its send buffer
Retransmitted packet arrives at the receiver
Buffer inserts the recovered packet into its sequence

All of this must complete before the buffer advances past the missing packet's playback position. If the retransmission arrives in time, it becomes an RTX Success. If it arrives too late or never arrives, the packet is declared lost.

RTX vs NACK

RTX requests at the jitter buffer level and NACK messages at the RTCP level often represent the same underlying mechanism — the buffer triggers the NACK. The distinction is perspective: NACK counts measure feedback messages sent, while RTX requests measure recovery attempts initiated by the buffer. They may not always be exactly equal due to timing and batching.

Why It Matters

RTX requests indicate that the buffer is actively fighting packet loss to maintain playback quality. A moderate count means the network is losing packets but the recovery mechanism is engaged. Whether this translates to quality problems depends on the success rate.

For SIP load testing, RTX requests reveal the hidden cost of packet loss. Even when final quality metrics look acceptable, a high RTX request count means the system is working hard behind the scenes to maintain that quality. This has implications:

Bandwidth overhead — Each retransmission consumes bandwidth. Under constrained links, retransmission traffic can compete with new media packets.
Latency pressure — The buffer may need to hold off playback slightly longer to give retransmissions time to arrive, increasing end-to-end latency.
Capacity indicator — A test that generates many RTX requests is closer to its quality limits than one that generates few, even if the final MOS scores are similar.

Thresholds

Level	Value (cumulative per stream)	Interpretation
Good	0 - 10	Minimal loss, few recovery attempts needed
Warning	10 - 50	Active loss recovery, network conditions degraded
Critical	Above 50	Heavy retransmission activity, system under stress

Common Causes of High RTX Counts

Cause	Explanation
Network packet loss	Packets dropped on the wire, requiring retransmission
Jitter-induced gaps	Packets delayed long enough to appear lost initially
Congestion	Network overload causing intermittent drops
WiFi loss	Wireless medium causing packet drops
Path MTU issues	Fragmented packets with some fragments lost

How to Fix It

Reduce network loss — RTX requests are a response to lost packets. Address the underlying loss by following Packet Loss guidance.
Calculate recovery ratio — Divide RTX Success by RTX Requests. A high ratio (above 80%) means retransmission is effective. A low ratio means retransmissions are failing and should be investigated.
Check round-trip time — RTX only works when the round-trip time is short enough for retransmitted packets to arrive before the playback deadline. High RTT reduces RTX effectiveness.
Monitor bandwidth — Heavy retransmission under constrained bandwidth can create a feedback loop: retransmissions consume bandwidth, causing more loss, causing more retransmissions.
Compare with NACK counts — If RTX requests differ significantly from NACK counts, investigate the discrepancy.

RTX Success — Packets successfully recovered, the positive outcome of RTX requests
Packet Losses — Packets the buffer declared lost despite RTX attempts
NACK Messages — RTCP-level retransmission requests
Late Packets — Some RTX responses may arrive too late and become late packets
Duplicates — When originals arrive after RTX was already requested