Summary

  • FIR 的八位序号用来区分同一 SSRC 对之间的新请求和重复请求；即使重传已经停止，这个数字也不是解码器状态或画面恢复证明。
  • 在 MCU 或切换器拓扑中，接收端到 MCU、MCU 到源端是两段独立的可靠性链路；管理层只有连接媒体、解码与呈现回执，才能声称用户已经恢复视频。

一个运行看板把 FIR 重传次数画成下降曲线。曲线归零，工单随即变绿，值班人员据此写下“刷新成功”。几分钟后，终端用户仍然面对冻结画面。系统并没有撒谎：它准确显示了控制请求不再重复。错误出在组织把“停止请求”提升成了“恢复完成”。

RFC 5104 在 AVPF 上定义了一组靠近媒体运行的编解码控制消息。Full Intra Request（FIR）要求媒体发送端尽快生成解码器刷新点；TSTR 与 TSTN 协商时间和空间质量取舍；VBCM 承载 H.271 反馈；TMMBR 与 TMMBN 处理临时最大媒体码率及其约束集合。这些消息共享 RTCP 反馈框架，却不共享一种通用的“成功”语义。

FIR 条目指向媒体发送端的 SSRC，并带有一个八位序号。序号空间属于发出反馈的 SSRC 与目标媒体 SSRC 这一对。真正的新请求把序号加一，并按 256 回绕；同一请求的重传必须保留原值。这使接收方能排除延迟副本，也避免编码器为重复控制包反复制造昂贵刷新帧。

八位计数器所能证明的范围很窄：在给定会话、给定 SSRC 对和可比时间上下文中，观察者看到的是哪一代请求。它没有字段说明编码器是否接受、何时生成、生成了哪些 RTP 包，也没有描述接收端是否拼出完整刷新点。跨会话、SSRC 重用或序号回绕时，如果丢掉上下文，相同数字甚至不能稳定代表同一件事。

RFC 的重传停止规则最容易被看板误读。请求方可以重复发送 FIR，直到收到所求刷新点。它在两种情况下都应停止：收到完整刷新点，或者发现一次刷新尝试因丢包而损坏。第二种情况不是成功，而是协议避免继续重复旧请求的一个状态转换。若仍需刷新，应用必须发出新的 FIR，使用新的序号。

因此，“最后一次 FIR 后没有再重传”至少有两种相反解释。其一，完整媒体到达，解码器有机会重建已知状态；其二，请求方识别出一次残缺尝试，旧请求的生命周期结束。没有媒体路径证据，控制曲线无法区分二者。自动化若把沉默当作肯定，便会把检测到的失败包装成恢复。

刷新点本身也不是单个抽象标记。RFC 把它定义为能把解码器完全重置到已知状态的一段比特序列，可以横跨一个或多个 RTP 包。它可能是帧内图像、H.264 IDR，或渐进式刷新过程；如果后续解码依赖序列参数等高层信息，那些信息也必须在带内可用。RFC 6184 展示了 H.264 负载化后，这种完整性为什么需要编解码器感知的观察，而不是只看某个包长或 NAL 类型。

编码器收到 FIR 后，应尽快发送刷新点，但仍必须服从拥塞控制。刷新图像可能比预测图像大许多，在受限码率下，其发送时间可能超过一个帧间隔。控制面记录“已处理”时，大包也许仍在排队；网络可能只交付其中一部分。RFC 的义务没有让队列、无线链路或拥塞瞬间消失。

若请求方在编码器发送刷新点后的两个往返时间以上仍重复同一 FIR，编码器应再次生成刷新点。这是一种提高成功概率的机制，而不是端到端确认。每个媒体发送端同一时刻只允许一个不同的 FIR 处于未决状态，约束了请求风暴，却也说明序号是控制代际，不是结果数据库。

为什么协议没有另设 FIR 成功通知？RFC 的设计理由是，刷新点在比特流中应当容易识别，请求方可以从数据路径判断，而不必相信另一个控制确认。这个选择把行动证据放到了媒体层：不是“对方说它做了”，而是“接收侧看到了符合编解码语义的尝试”。

但媒体识别也只完成了一层。接收侧解析器可以证明相关包构成完整或损坏的刷新尝试；解码器回执才能证明参考状态已经重置；渲染器或应用回执才能说明新画面实际呈现。若服务承诺是用户恢复可用视频，最后还需要用户路径或应用层指标。每层都应保留自己的权威边界。

MCU 场景使边界更清晰。RFC 5117 描述了多种 RTP 拓扑。切换 MCU 收到来自观看者的 FIR 后，可能向当前选中的源端产生另一条 FIR。RFC 5104 明确要求这两段可靠性分别处理：观看者到 MCU 的请求到达，并不证明 MCU 到源端的请求到达；源端生成刷新点，也不证明 MCU 向原观看者完整转发。

在切换期间，控制记录尤其容易失真。MCU 先选择 A，收到 FIR 后向 A 请求刷新，随后又切到 B。A 的刷新包可能完整抵达 MCU，却已不属于请求者当前看到的媒体时期。一个全局“FIR 完成”字段会抹掉选择映射、SSRC、链路和时钟。正确记录必须说明哪个请求、面向哪个源、在哪段拓扑、对应哪一段媒体。

FIR 也不应成为普通画面丢失的万能响应。RFC 4585 定义 Picture Loss Indication；RFC 5104 建议对一般画面丢失使用 PLI，而把 FIR 留给缺少刷新会使视频不可用的场景，例如没有周期刷新时新参与者加入，或 MCU 切换到不同编码源。把每次丢包都升级成 FIR，会制造额外带宽压力和卡顿。

同一 RFC 中其他消息进一步说明，反馈并不等于确认。TSTR 请求改变时间与空间分辨率的权衡，TSTN 报告发送端实际选择的取舍；发送端可能综合多个接收者和本地策略，因此报告值不必等于请求值。这里的通知是选择结果，不是原请求被原样执行的证明。

TMMBR/TMMBN 又是另一套契约。接收者提交临时最大总媒体码率与每包开销元组，发送端计算可行区域及形成边界的元组集合，再通知所有者。即使新元组没有进入边界集合，发送端仍须回复 TMMBN。因此，收到通知既不证明具体请求被采纳，也不证明质量已经改善。

码率观察还取决于层级。发送端和接收端可能在协议栈不同位置计数，看到的总媒体码率因开销而不同。TMMBR 表达的是观察者所知约束，不保证覆盖全路径。RFC 8083 也强调 RTCP 反馈必须与拥塞控制协调。把 FIR、TSTR 和 TMMBR 都压成“反馈成功”，会丢掉故障分析最重要的语义差别。

安全保护提高命令的可信度，却不能替代结果证据。RFC 5104 警告，伪造反馈可以迫使码率降得很低、篡改边界所有权、施加不需要的质量偏好，或触发过多刷新点使视频抖动。RFC 3711 与 RFC 5124 提供 SRTP/SAVPF 的认证和完整性环境。

经过认证的 FIR 可以支持“某个会话主体在受保护上下文中发出了这些字节”这一判断。它不能授权控制包替编码器日志、RTP 交付记录、解码器状态或屏幕画面作证。身份真实回答谁说了话；下游执行成功仍需下游自己的记录。

标准沿革也要求保留语境。RFC 5104 仍是 Proposed Standard，后来由 RFC 7728 针对 RTP 流暂停与恢复进行更新，又由 RFC 8082 补充可分层编解码器控制。只识别原始消息名、忽略暂停状态和层级目标的采集器，即使字段解析正确，也可能给出错误运营结论。

领导层需要的不是更大的绿色灯，而是可连接、不可越权的证据链。至少记录 RTP 会话与安全上下文、FIR 源和目标 SSRC、请求序号、首次发送和每次重复、MCU 或转换器链路、编码器接收、编解码器特定刷新生成、RTP 包范围与丢失、请求方判断完整或损坏、解码器重置、渲染结果，以及应用定义的用户可见恢复。时钟误差和拓扑变化应被明确保留。

这与 Lu Heng 的现实层原则相符。控制层可以诚实声明命令已发出；媒体层可以声明刷新尝试已到达；解码器可以声明参考状态已重建；呈现层可以声明画面已显示。组织可以在决策层连接这些回执，但任何一层都不应借用下一层尚未产生的权威。

Sources