Jitter Buffer RTX Success

Jitter buffer RTX success is a cumulative count of packets that were successfully recovered through retransmission. Each successful recovery means a packet that was initially missing from the stream was re-requested, retransmitted by the sender, and arrived at the buffer before the playback deadline — saving the user from experiencing a gap in the media.

Think of it as the number of times the courier successfully re-delivered a lost package before you needed it. Each success is a problem that was invisibly resolved.

How It Works

When the jitter buffer detects a missing packet and sends an RTX request, the sender retransmits the packet. If the retransmitted packet arrives before the buffer's playback point advances past that sequence number, the recovery is successful:

1. Buffer detects gap, sends RTX request
2. Sender retransmits the packet
3. Retransmitted packet arrives at the buffer
4. Buffer verifies it arrived before the playback deadline
5. Packet is inserted into the buffer at its correct position
6. RTX success counter increments

The packet then plays out normally as if it were never lost. The user experiences no gap, artifact, or quality degradation from that specific loss event.

Why It Matters

RTX success is the good news metric in the loss recovery chain. While RTX requests tell you how often recovery was attempted, RTX success tells you how often it actually worked. The ratio between the two reveals the health of your retransmission path.

For SIP load testing, the recovery ratio is a critical quality indicator:

A system with high packet loss but a high recovery ratio may deliver acceptable quality. Conversely, a system with moderate loss but a low recovery ratio will show worse quality than expected, because losses are not being repaired.

Key Relationships

Understanding RTX success requires looking at it alongside other metrics:

• RTX Success is high, Buffer Losses are low — Retransmission is saving the day. Quality is maintained despite network loss.
• RTX Success is low, Buffer Losses are high — Retransmission is failing. The system cannot recover from network-level loss.
• RTX Success is high, Duplicates are also high — Many originals are arriving late, overlapping with retransmissions. The network has high jitter rather than true loss.
• RTX Success is zero, RTX Requests are high — Retransmission path is completely broken. The sender may not support RTX, or the retransmitted packets are also being lost.

How to Improve Recovery

1. Reduce round-trip time — Shorter RTT gives retransmitted packets more time to arrive before the playback deadline. Geographic proximity and efficient routing help.
2. Ensure sender supports RTX — Verify that the remote endpoint has retransmission enabled and its send buffer retains packets long enough to service RTX requests.
3. Increase buffer capacity — A larger jitter buffer creates a wider window for retransmissions to arrive. The trade-off is increased latency.
4. Check the retransmission path — RTX packets travel the same network path as regular media. If that path is lossy, retransmissions themselves may be lost. Consider whether the loss is random (retransmissions have the same loss probability) or concentrated (bursts that affect both originals and retransmissions).
5. Correlate with RTT — If RTT is close to or exceeds the buffer delay, retransmissions mathematically cannot arrive in time. Either reduce RTT or increase buffer depth.

Related Metrics

• RTX Requests — Total retransmission attempts; divide success by requests for recovery ratio
• Packet Losses — Unrecoverable losses that RTX could not fix
• Duplicates — Packets received twice, often because the original arrived after RTX was sent
• NACK Messages — RTCP-level view of retransmission requests
• Packets Pushed — Total delivered packets, includes both original and recovered