NACK stands for Negative Acknowledgement. It is one of the error resiliency mechanisms in WebRTC.

NACK is a way for the receiving end to indicate it hasn’t received a specific packet.

A NACK message is sent over RTCP to the sender of the media, which in turn needs to decide if it will retransmit the lost packet based on its availability in its cache and its estimate to the usefulness of the retransmission (will it be possible to use it once received).

Mechanism of NACK

The mechanism of NACK is straightforward yet crucial for maintaining the quality of the communication link. When a receiver detects the absence of a specific packet, it triggers a NACK message.

This message is then transmitted over RTCP (Real-Time Control Protocol) to the sender of the media. The onus now lies on the sender to evaluate the request for retransmission.

Decision on Retransmission

Upon receiving a NACK message, the sender has to make a calculated decision regarding the retransmission of the lost packet.

This decision hinges on two primary factors: the availability of the packet in its cache and the estimated usefulness of the retransmission.

The sender evaluates whether the retransmitted packet, once received, will still hold value for the ongoing communication.

Importance in WebRTC

The implementation of NACK in WebRTC is pivotal as it directly impacts the quality and reliability of the real-time communication.

By providing a mechanism to request for lost packet retransmission, NACK plays a vital role in mitigating the effects of packet loss, thereby enhancing the overall user experience in a WebRTC environment.