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 to the sender of the media. The responsibility 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
- The estimated usefulness of the retransmission
The sender evaluates whether the retransmitted packet, once received, will still hold value for the ongoing communication. If it doesn’t, he won’t retransmit it.
Importance in WebRTC
The implementation of NACK in WebRTC directly impacts the quality and reliability of the real-time communication. It is focused on video streams and a lot less on audio streams.
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.
