Summary

  • A Full Intra Request is a codec-scoped RTCP command. Its target SSRC and eight-bit request sequence identify one command generation; they do not show that a refresh point arrived intact or reset the requesting decoder.
  • RFC 5104 closes the FIR reliability loop by observing the media stream, not by inventing a generic control acknowledgement. Delivery, decoding, rendering and user recovery therefore need their own joined receipts.

A video switch changes speakers. The controller sends a Full Intra Request to the newly selected source. The message is authenticated, its sequence number is fresh and the sender stops repeating it a moment later. An operations panel can turn those facts into a reassuring sentence: refresh complete.

That sentence has crossed several boundaries that RFC 5104 keeps separate.

The RFC extends the RTP Audio-Visual Profile with Feedback, or AVPF, with six codec-control messages. FIR requests a decoder refresh point. TSTR and TSTN negotiate a temporal-spatial trade-off. VBCM carries H.271 back-channel information. TMMBR and TMMBN establish a temporary media-rate constraint and report its bounding set. All travel close to the media because their value decays with delay. None turns RTCP into a general-purpose session-control authority.

FIR has a deliberately narrow job. Its Feedback Control Information names the SSRC of the media sender that should produce a refresh point. An eight-bit command sequence belongs to the pairing of the command-source SSRC and command-target SSRC. Each new command increments that value modulo 256. A repetition keeps the same number.

This design answers two useful questions: which source-target relationship issued the command, and whether a received packet is another copy of an outstanding request or a new request. It does not answer whether the encoder accepted the request, whether the requested media was generated, whether its packets survived the path or whether any decoder returned to a known state.

RFC 5104 defines that known state carefully. A decoder refresh point is a bit string, carried in one or more RTP packets, that completely resets the decoder. Depending on the codec, it may be an intra picture, an IDR picture or a gradual refresh. It also needs the in-band information above the picture layer that the following coded units depend on. A visually large frame is not automatically a valid refresh point, and a refresh point visible at the sender is not automatically the same object that arrived at a receiver.

Upon receiving FIR, the encoder must send a decoder refresh point as soon as possible. “As soon as possible” is not “immediately” and not “already delivered.” The RFC requires the sender to honour congestion control, which may slow the response. Refresh points are commonly several times larger than predicted pictures. Under a low available bit rate, their transmission can take much longer than an ordinary picture interval.

That constraint matters operationally. A control log can show a valid command and an encoder log can show that refresh generation began. Neither proves that all packets reached the requesting side before a stream switch, a timeout or another topology change. A deadline imposed by an application is not rewritten by the protocol's obligation to pace the burst.

The reliability rule makes the evidence boundary explicit. A FIR sender may repeat the request until it receives the desired content. It must also stop when it detects an attempted decoder refresh point that was damaged by packet loss. The stopping event can therefore mean either complete refresh content or an identifiable but incomplete attempt. “FIR repetition stopped” is not synonymous with “decoder recovered.”

If a genuinely new FIR is needed, the requester increments the sequence number. Only one distinct FIR may be outstanding per media sender. Repetitions more than two round-trip times after the encoder sent a refresh point cause the encoder to send another one. These rules suppress duplicate work and improve delivery probability. They do not make an eight-bit counter into an execution receipt.

Why is there no FIR notification? RFC 5104 says decoder refresh points are readily identifiable in the bit stream. The requester can therefore derive closure from the media rather than depend on a protocol-level acknowledgement. This is an important architectural choice. The evidence of action sits on the data path.

An acknowledgement would establish only that an entity emitted the acknowledgement. Media observation can establish that an attempted refresh was present. Even that observation still stops short of decoder and rendering state. The requester needs a codec-aware parser to identify completeness, then a decoder receipt to establish reset, and finally a presentation receipt if the claim is that a person received usable video.

The distinction becomes sharper in a multipoint topology. An RTP mixer or switching MCU that receives FIR is responsible for ensuring a refresh point reaches the requesting receiver. It may generate another FIR toward the selected origin. RFC 5104 treats the requester-to-MCU and MCU-to-origin legs independently for reliability.

One row in a central controller cannot safely compress those legs. The inbound FIR may reach the MCU while the outbound FIR is lost. The origin may generate a refresh while the MCU's selected-source mapping changes. The MCU may receive the refresh and still fail to forward the complete packet range to the original requester. Each leg needs its own SSRC scope, security context, sequence generation, clock and media observation.

FIR is also not a universal answer to damaged video. The RFC says it should not be sent in reaction to ordinary picture loss; Picture Loss Indication from RFC 4585 is recommended there. FIR is reserved for circumstances in which withholding a refresh would leave video unusable, such as admitting a new participant when no regular refresh interval exists or switching an MCU to a different encoded source.

That difference protects both the network and the evidence. Frequent refresh points can consume substantially more bandwidth, reduce frame rate and make video jerky. A system that converts every loss alarm into FIR can create the degradation that its dashboard then attributes to the path. The command policy, loss observation and later quality result must remain separately reviewable.

The other RFC 5104 messages demonstrate why a feedback exchange cannot be read as a single kind of acknowledgement. TSTR asks an encoder to change the trade-off between temporal and spatial resolution. TSTN reports the trade-off the sender actually chose. The returned index need not equal the requested one, because the encoder may reconcile several receivers, local coding policy and available resources.

TMMBR and TMMBN have another contract. A receiver reports a maximum total media bit rate and per-packet overhead tuple. The sender calculates a feasible region and a bounding set of tuples, then announces the set and its owners. A TMMBN must be emitted in response even when the newly received tuple does not enter that set. Receipt of the notification therefore proves neither acceptance of that particular request nor a measured quality result.

The maximum is observer- and layer-dependent. RFC 5104 notes that total media bit rate can differ between sender and receiver because they may count at different protocol layers and encounter different overhead. TMMBR expresses known constraints, often local ones, and gives no guarantee about the full path. Increasing a limit still requires congestion control and a delay during which other receivers can assert a stricter bound.

These semantics resist a common dashboard habit: displaying “request acknowledged” as though FIR, TSTR and TMMBR shared one completion model. FIR has no explicit notification and looks for media. TSTR receives a notification of the chosen value, which may differ. TMMBR receives a view of a bounding set, which may exclude the new tuple. The message name, response shape and evidence of outcome are different in each case.

Security adds authenticity without merging the layers. RFC 5104 warns that forged feedback can force a very low bit rate, assign bounding ownership incorrectly, impose unwanted temporal-spatial preferences or trigger enough refresh points to make video jerky. It calls for authentication and integrity protection of setup signaling and feedback. RFC 3711 and the SAVPF profile in RFC 5124 provide the relevant protection context.

An authenticated FIR is stronger evidence than an unauthenticated packet. It can support a claim about the command's session principal, protected transport and bytes. It still does not grant the command authority over the encoder log, RTP delivery record, decoder state or rendered frame. Authenticity answers who spoke within a security context; it does not prove that every downstream system acted successfully.

The standards history also matters. RFC 5104 remains a Proposed Standard but is updated by RFC 7728 for RTP stream pause and resume and by RFC 8082 for layered codecs. A collector that recognizes only the original message vocabulary can still misinterpret a later session if it ignores updated negotiation and layer context. Publication status is not runtime conformance, and conformance is not recovery.

A defensible incident ledger should therefore keep a joined chain rather than one green field. Record the RTP session and security context; FIR source and target SSRCs; request sequence; first transmission and repetitions; mixer or translator leg; encoder receipt; codec-specific refresh generation; RTP packet range and path loss; requester recognition of a complete or damaged attempt; decoder reset result; rendered-frame result; and the application's user-visible recovery signal. Preserve clock uncertainty and topology changes. Do not log media contents merely to prove the chain.

That evidence model follows Heng Lu's reality-layer discipline. A record earns trust by remaining inside the layer that produced it. The FIR ledger may say the right command was sent. The media ledger may say a refresh arrived. The decoder may say its reference state was reset. The renderer may say a frame was presented. Leadership may join those receipts into a service judgment, but none should borrow the authority of the next.

Sources