FIR Messages
Understand FIR (Full Intra Request) messages — the strongest keyframe request mechanism, when it triggers, and what it means for video quality.
FIR stands for Full Intra Request. It is the strongest signal a video receiver can send to demand a complete keyframe from the sender. While a PLI politely indicates that some picture data was lost, a FIR is an urgent command: "Send a full I-frame immediately — my decoder state is completely broken."
Think of it as pulling the emergency brake. The receiver has determined that no amount of incremental repair will fix the problem, and only a complete fresh start will restore the video.
How It Works
A FIR message is sent via RTCP when the receiver's decoder has lost synchronization with the sender's encoder state. This can happen due to severe packet loss, decoder errors, or situations where the receiver joins mid-stream and has never received a keyframe.
Unlike PLI, which is a general hint, FIR is defined in a separate RFC (RFC 5104, Codec Control Messages) and carries a sequence number to prevent duplicate processing. The sender is expected to respond by immediately encoding a full intra-coded frame, regardless of its normal keyframe schedule.
FIR vs PLI
While both request keyframes, FIR is more forceful. Some encoders treat PLI as advisory and may delay the keyframe. FIR demands an immediate response. If you see FIR messages when PLI should suffice, it may indicate that the sender is not responding to PLI requests quickly enough.
Why It Matters
FIR messages indicate severe video decoding failures. Each FIR means the receiver has completely lost the ability to display video and needs a full reset. Between the FIR request and the arrival of the new keyframe, the user sees a frozen or black screen.
In SIP load testing, FIR counts reveal how well your infrastructure handles video under stress. A system that generates frequent FIR messages is failing to deliver reliable video, even if the calls themselves remain connected. This is especially critical for video conferencing systems, telepresence, and video surveillance over SIP.
Thresholds
| Level | Value (per second) | Interpretation |
|---|---|---|
| Good | 0 - 3 | Rare decoder resets, acceptable for most scenarios |
| Warning | 3 - 15 | Frequent decoder failures, visible disruptions |
| Critical | Above 15 | Continuous decoder state loss, video is unusable |
Common Causes of High FIR Counts
| Cause | Explanation |
|---|---|
| Severe packet loss | Loss so heavy that NACK and PLI cannot recover |
| Decoder state corruption | Decoder encountered invalid data and lost sync |
| Late stream join | Receiver started receiving mid-stream without an initial keyframe |
| SFU switching | Media server switching between video sources without sending keyframes |
| Encoder not honoring PLI | Sender ignoring PLI requests, forcing receiver to escalate to FIR |
How to Fix It
- Investigate PLI handling — If FIR counts are high but PLI counts are low, the sender may not be responding to PLI requests. Verify that your video infrastructure processes PLI feedback correctly.
- Reduce packet loss — FIR is the end of the escalation chain. Fixing the underlying loss (see NACK and Packet Loss) prevents the cascade from reaching FIR.
- Configure periodic keyframes — Set a reasonable keyframe interval (e.g., every 2-3 seconds) so that even without feedback, receivers periodically get a fresh reference frame.
- Check media server behavior — If calls route through an SFU or B2BUA, ensure it forwards RTCP feedback correctly and generates keyframes during participant switches.
- Verify encoder health under load — Encoders under CPU pressure may fail to produce keyframes on demand. Monitor encoder capacity during stress tests.
Related Metrics
- PLI Messages — The standard keyframe request that FIR escalates from
- NACK Messages — Packet-level retransmission, the first recovery mechanism
- SLI Messages — Partial frame loss indication, less severe than both PLI and FIR
- Freeze Count — User-visible impact of decoder failures
RFC Reference
FIR is defined in RFC 5104 (Codec Control Messages in the RTP Audio-Visual Profile with Feedback), Section 3.5.1. It uses the RTCP Payload-Specific Feedback Message type (PT=206) with FMT=4. Each FIR message includes a sequence number to allow the sender to detect and ignore duplicate requests.