NACK Messages

Understand NACK (Negative Acknowledgement) messages in video RTP streams — what they measure, why they matter, and how to reduce retransmission requests.

NACK stands for Negative Acknowledgement. When a video receiver detects that an RTP packet is missing, it sends a NACK message back to the sender asking it to retransmit the lost packet. Each NACK message represents one recovery attempt for a missing piece of video data.

Think of it like requesting a page to be re-sent because it was lost in the mail. A few re-sends are normal; a flood of them means something is wrong with the delivery path.

How It Works

During a video call, the receiver tracks the sequence numbers of incoming RTP packets. When it notices a gap in the sequence (a missing packet), it immediately sends a NACK to the sender via RTCP feedback. The sender then retransmits the missing packet from its buffer. This mechanism is part of the AVPF (Audio-Visual Profile with Feedback) defined in RFC 4585.

NACK-based retransmission is the first line of defense against video packet loss. It is faster and more efficient than requesting an entirely new keyframe because only the specific missing packet needs to be re-sent.

Video only

NACK messages apply exclusively to video streams. Audio codecs typically do not use retransmission because the added delay would be more disruptive than the brief gap caused by a lost audio packet.

Why It Matters

A moderate NACK count is normal — networks occasionally drop packets, and retransmission recovers them transparently. However, a high NACK count signals persistent packet loss on the network path. When the loss rate exceeds what retransmission can recover, video quality degrades rapidly: frames cannot be decoded, artifacts appear, and eventually the video freezes entirely.

For enterprise VoIP testing, NACK rates are a leading indicator of network health. Rising NACK counts during a load test often reveal bandwidth bottlenecks before they become visible as frozen video.

Thresholds

Level	Value (per second)	Interpretation
Good	0 - 10	Normal operation, occasional retransmissions
Warning	10 - 50	Elevated packet loss, investigate network path
Critical	Above 50	Severe loss, video quality likely degraded

Common Causes of High NACK Counts

Cause	Explanation
Network congestion	Routers drop packets when buffers overflow under heavy load
Insufficient bandwidth	Video bitrate exceeds available capacity
Firewall or NAT issues	Stateful firewalls may drop UDP packets under load
WiFi interference	Wireless links introduce unpredictable packet loss
QoS misconfiguration	Video traffic not prioritized, dropped during congestion

How to Fix It

Check network bandwidth — Ensure the link can sustain the video bitrate with headroom. A 1 Mbps video stream needs well over 1 Mbps of available bandwidth to account for overhead and bursts.
Enable QoS/DSCP marking — Mark video RTP packets with appropriate DSCP values (e.g., AF41) so network equipment prioritizes them over best-effort traffic.
Reduce video bitrate — If bandwidth is limited, lowering the video bitrate reduces the number of packets and the likelihood of drops.
Use wired connections — Replace WiFi with Ethernet where possible to eliminate wireless packet loss.
Review firewall rules — Ensure firewalls allow the full RTP port range and do not throttle UDP traffic.

PLI Messages — When NACKs fail to recover the lost data, the receiver escalates to a PLI requesting a full keyframe
FIR Messages — The most severe keyframe request, triggered when decoder state is completely lost
Packet Loss — The underlying network-level metric that drives NACK generation
RTX Requests — Retransmission requests at the jitter buffer level

RFC Reference

NACK messages are defined in RFC 4585 (Extended RTP Profile for Real-time Transport Control Protocol Based Feedback), Section 6.2.1. The Generic NACK format uses the RTCP Feedback Message type (PT=205) with FMT=1.