How WebRTC Uses NACK to Recover Lost Packets

This article provides an overview of how WebRTC utilizes Negative Acknowledgment (NACK) to recover lost media packets during real-time communication. You will learn how the sender and receiver coordinate using RTP sequence numbers, the role of the retransmission buffer, and how WebRTC balances packet recovery with low-latency constraints.

Real-time communication protocols like WebRTC prioritize speed and low latency, which is why they transmit media over UDP instead of TCP. While UDP is fast, it does not guarantee packet delivery. To prevent audio and video degradation caused by network congestion and packet loss, WebRTC employs a feedback mechanism known as Negative Acknowledgment (NACK). Unlike traditional acknowledgment (ACK) systems that confirm every successfully received packet, NACK only alerts the sender when a specific packet fails to arrive.

The NACK process begins at the receiver’s end through the monitoring of Real-time Transport Protocol (RTP) sequence numbers. Every media packet sent via WebRTC is assigned a sequential number. If a receiver gets packet 101 and packet 103, but packet 102 is missing, the receiver detects a gap in transmission. After a brief wait to account for out-of-order delivery, the receiver generates an RTCP (RTP Control Protocol) NACK message containing the sequence number of the missing packet (102) and sends it back to the sender.

Upon receiving the NACK message, the sender checks its local retransmission buffer. This buffer is a temporary cache where recently transmitted RTP packets are stored. If the requested packet is still in the buffer, the sender immediately retransmits it to the receiver. If the packet is no longer in the buffer—usually because it is too old—the sender ignores the request, and the receiver’s decoder must handle the loss using error concealment or by requesting a new keyframe.

To ensure smooth playback, the receiver uses a jitter buffer. This buffer temporarily holds incoming packets to allow time for the retransmitted “lost” packet to arrive and be reinserted into the correct sequence before decoding. Because this entire loop must happen within milliseconds to prevent visible glitches or audio dropouts, WebRTC dynamically measures the Round-Trip Time (RTT). If the RTT is too high, WebRTC may disable NACK and rely on Forward Error Correction (FEC) instead, as retransmitting packets over a high-latency connection would arrive too late to be useful.