摘要

  • RFC 5109 的每个 ULP 保护层都有自己的包掩码和保护长度；一层可解，并不证明其他层也可解。
  • FEC 包到达、关键前缀重建、整包恢复、解码器接受和按时播放，是五张不同的收据。

两个分组，两种结果

ULP 并不把“有无 FEC”当作一个开关。发送端把包内数据按重要性分层，通常让靠前部分进入更小、保护更强的分组，让靠后部分进入更大、开销更低的分组。一个 FEC 包可以携带多层奇偶校验，但每层独立计算。

因此，同一丢包可以在 0 级方程里是唯一未知量，在 1 级方程里却与另一个丢包同时未知。前一方程能够用 XOR 重建 RTP 恢复字段与一段负载；后一方程无法唯一求解。结果不是“恢复”或“未恢复”的二选一，而是一个有明确字节边界的部分包。

RFC 5109 要求用 0 级恢复出的总长度，与实际重建的负载长度比较。两者不相等，就说明恢复没有覆盖整包。把“头部存在”升级为“媒体包恢复”，等于丢掉协议专门提供的完整性判据。

掩码说明成员，长度说明表面

每个 FEC 层头包含 16 位 Protection Length，以及 16 位或 48 位掩码。若序列号基值为 N，掩码第 i 位为 1，就表示该层方程包含媒体包 N+i。掩码回答“哪些包进入方程”，长度回答“每个包的哪些字节受保护”。它们都不回答接收端是否拥有其余操作数。

层之间有嵌套约束：包若在 p 层受保护，也必须在 p-1 层受保护；携带 p 层的 FEC 包也要携带前一层。不过，不同层的包集合可以不同，同一媒体包的相邻层也可位于不同 FEC 包。仅记录“该序列号受 FEC 覆盖”无法还原真实保护几何。

先选方程，再重建字节

恢复分成两个动作。接收实现先自行选择可组合的媒体包与 FEC 包；不同算法在搜索复杂度、CPU 预算和发现可解组合的能力之间取舍。选定之后，才按规范执行字节重建。

这意味着可解方程可能存在，却未在播放期限内被找到；也可能只为 0 级找到，而高层仍无解。对第 n 层，接收端读取长度 Ln，在累计偏移处截取操作数，对较短操作数补零，执行 XOR，再把结果放回该层位置。多个层结果拼接后，才能用总长度判定整包是否完成。

可审计记录至少包括：基值、掩码、层号、保护长度、实际到达的操作数、未知量个数、重建字节区间、预期总长度和完整性比较。单一 recovered_packets 计数无法回答这些问题。

媒体可播放，不证明修复生效

当 FEC 走独立 RTP 会话时，原媒体包保持不变。不支持 FEC 的接收端可以忽略保护数据，继续消费媒体。在 offer/answer 中，接收方还能拒绝独立 FEC 会话，同时接受媒体会话。因此，看见画面不证明接收端协商、收到或使用了 ULPFEC。

FEC 也可以作为 RFC 2198 冗余编码承载。独立会话模式必须在带外说明地址、端口、动态负载类型以及它保护哪个媒体流。媒体和 FEC 可能走不同路径、拥有不同序列空间并遭遇不同损失。证据链应保存提议、应答、关联版本、两路到达情况和真正采用的方程。

重建字节仍需怀疑

奇偶校验不是认证。RFC 5109 指出，篡改 FEC 数据可能改变结果、制造过长包，或显著放大恢复计算量。实现应在计算前检查输入合理性，并在使用前验证输出。一个代数上可解的方程，仍可能产生不应送入解码器的数据。

即使前缀正确，也不能自动推断可解码。ULP 的失败往往表现为连续尾部缺失；某些媒体格式可能利用前缀，另一些格式的依赖可能跨过缺口。RFC 没有替具体编码器、具体播放期限或用户体验作保证。

修复也会占用拥塞路径

更高冗余通常提高抗损能力，也提高总带宽。如果丢包源于拥塞，自动加码 FEC 会加重原因本身。RFC 5109 要求：随着网络损失增加，媒体加 FEC 的总用量不得显著增加，并要求 best-effort 使用者监控损失。

所以保护策略变化必须与总速率、媒体速率、队列时延、丢包和播放迟到共同评估。更多“恢复前缀”若换来更长队列，不等于服务改善。

标准的边界

RFC 5109 于 2007 年 12 月以 Standards Track 发布，取代 RFC 2733 和 RFC 3009，修正 RTP 头处理并加入不均等保护。它的 FEC 格式与旧格式不向后兼容，但未修改的媒体仍可能被旧接收端消费。这是协议兼容性，不是部署或效果证据。

掩码最多覆盖 48 个偏移，算法采用 XOR。文档没有证明任何具名运营商、产品、编码器、实际丢包率、恢复比例或观看质量。可成立的结论是：RFC 5109 允许系统精确说明保护意图与重建范围，却不允许把一张方程收据当作整包或服务结果。

来源