摘要

  • RFC 5124 将 AVPF 与 SAVP 组合为 SAVPF，没有把两层的职责混成一个结果承诺。
  • AVPF 仍决定 RTCP 反馈何时发送，SAVP 随后把该报文处理为 SRTCP。
  • SAVPF 下的全部 RTCP 报文都必须采用 RFC 3711 的 SRTCP 封装。
  • 安全字段会增加报文大小；RFC 5124 所述场景约增加 10 至 20 字节，默认例子为 14 字节。
  • 实现必须让 avg_rtcp_size 反映受保护报文的实际大小，否则调度器会高估反馈频率。
  • 在 N <= B*T/R 的粗略关系中，平均报文大小 R 增加，会减少同一时限内可报告的事件数。
  • SDP 中出现 SAVPF 只证明某个媒体描述选择了该配置，不证明密钥已经建立或报文已经验证。
  • SRTCP 完整性是强制项，但加密可以为 NULL；群组密钥下的有效标签也不必然锁定唯一发送者。
  • 接收端可能因密钥时期、算法、索引或重放窗口不匹配而丢弃格式正确的反馈包。
  • 同时提供安全与非安全候选会产生降级风险，选择过程本身必须受到保护。
  • 协商按媒体描述进行，一条视频线失败并不证明音频也失败，一条成功也不能替整次会话背书。
  • 运维必须分别保留能力、报价、受保护选择、密钥、包验证、预算、时限、动作和呈现结果。

一个绿色标识与一个红色丢包计数

控制面板显示 RTP/SAVPF。发送端和接收端也确实完成了 SDP 交换。但接收端日志同时记录：某个 SRTCP 反馈包被重放窗口拒绝。两个事实可以同时成立。前者是媒体配置的选择凭据，后者是实际报文在某个密码上下文中的处理结果。

如果系统只保留前者，事故报告就会把“配置正确”误写成“反馈可靠”。如果只看丢弃计数，又可能错怪协议选择；真正的原因也许是旧密钥时期的迟到报文、索引状态丢失、节点切换后上下文未同步，或者重放检测按设计工作。RFC 5124 的价值正在于它没有要求人们用一个标签覆盖这些事实。

SAVPF 是组合协议。RFC 4585 定义 AVPF，让接收端能在常规 RTCP 周期之前发送某些反馈。RFC 3711 定义 SAVP/SRTP 与 SRTCP。RFC 5124 保持 AVPF 层的调度逻辑不变，等上层决定报文可以发出后，再由安全层添加字段并执行变换。它没有创造新的端到端身份体系。

安全尾部进入了时间公式

反馈控制带宽是有限的。一个接收端多久能发一次报告，取决于分配给 RTCP 的带宽、群组规模、平均报文大小、事件频率以及应用的时限。SRTCP 在普通 RTCP 后增加索引、认证标签等字段。RFC 5124 估计其讨论的配置通常增加至少 10 至 20 字节，并以 14 字节作为默认情形。

这不是要求所有实现永远加十四个字节。不同认证标签长度、主密钥标识符或后来定义的变换都可能改变开销。真正的规范要求是：avg_rtcp_size 必须按照 SRTCP 报文计算。把加密之前的平均大小留在调度器里，等于用不存在的短包分配发送机会。

RFC 4585 用 N <= B*T/R 粗略描述 Immediate Feedback 区域。N 是时段 T 内平均需要报告的事件数，B 是这个接收端可用的 RTCP 带宽，R 是平均 RTCP 报文大小。其他条件不变时，R 增加，能在期限内装下的事件就减少。

因此，安全成功不消除性能代价。密码计算全部正确，反馈仍可能从“几乎每个事件立即报告”退到“挑选部分事件提前报告”。再往外，群组和时间尺度可能使单个事件反馈失去意义。这三个区域分别是 Immediate Feedback、Early RTCP 与 Regular RTCP，不是一个“已启用”布尔值。

及时性不是密码属性

RFC 4585 用 T_max_fb_delay 表示某个反馈仍有用的最大延迟。它由应用决定，没有一个适用于全部编解码器、缓冲区和媒体类型的统一数字。一个 NACK 可以通过 SRTCP 完整性和重放检查，却在画面播放期限之后才到达。

反过来，报文按时抵达也不证明媒体恢复。发送端可能没有缓存原包，可能选择其他自适应动作，也可能发送重传而再次丢失。解码器即使收到数据，也可能已丢失参考状态。RFC 5124 只给反馈提供组合后的安全传输规则，不承诺发送端动作或最终画面。

应当按顺序记录：接收端发现事件的时间、AVPF 排程时间、SRTCP 发送时间、网络到达时间、认证接受时间、发送端决定、后续媒体包到达、解码器状态与用户可见结果。每一项都有不同故障面。

“安全”必须写明是哪一种安全

RFC 3711 可以提供机密性、完整性或消息认证以及重放保护。SRTCP 完整性是强制的，因为被篡改的控制报文会扰乱媒体处理。但加密是另一个维度，规范允许 NULL 加密。因此，有效的 SAVPF 会话不能自动被描述为“所有控制内容均保密”。

在某些群组通信模型里，多方持有同一组材料。有效标签可以说明报文来自密钥持有集合，却不能总是指出具体哪一方。RFC 3711 自己提醒，此时日常所称的“认证”可能更准确地只是完整性保护。身份结论取决于密钥分配与信任模型，而不是术语看起来有多强。

实际报文验证需要算法、会话密钥、主密钥、SRTCP 索引、重放窗口、上下文生命周期，以及可能存在的 MKI。SDP 中的 SAVPF 字符串没有携带这些运行结果。运维界面若不显示当前上下文标识，就无法解释为何“同一配置”下有些反馈被接收、有些被拒绝。

先保护选择，再保护报文

攻击者可能根本不碰 SRTCP。RFC 5124 警告，在同一报价中同时列出安全与非安全 RTP 配置，会引入 bidding down 等攻击。如果确实要这样做，协商信令必须得到适当保护。

“优先选择安全项”只是本地策略。真正的降级抵抗还要证明报价内容、顺序、反馈属性和应答没有被第三方删除或改写。SRTCP 在配置和密钥生效之后才工作，无法追认之前未受保护的 SDP 交换。

对一个媒体描述，AVP、AVPF、SAVP 与 SAVPF 是互斥选择。应答方若不支持报价中的 SAVPF，必须拒绝该媒体。若报价没有 SAVPF 而应答方希望使用它，也必须拒绝，并可在后来另开报价。它不能在应答里静默“升级”，因为那并非双方同意。

会话边界比产品边界更细

RFC 5124 允许 SAVP 与 SAVPF 实体在同一个安全 RTP 会话里共存；AVP 与 AVPF 也能在同一个非安全会话里共存。但安全家族与非安全家族不得混在同一 RTP 会话，因为 RTP 和 SRTP 的线上格式不能这样互换。不同 RTP 会话则可以采用不同配置。

这意味着“该产品支持 SAVPF”信息量很低。音频可能采用 SAVPF，视频可能被拒绝；一个旧端点可能能收安全媒体却不能发提前反馈；另一个端点可能声明支持，但没有可接受的密钥方式。正确索引应至少包括媒体描述、RTP 会话、传输地址、配置、密码时期和反馈能力。

RFC 5124 所述 RTSP 流程更强调状态变化：客户端在 SETUP 中为每条流选择恰好一个配置，服务器确认或拒绝。当时的流程要改变配置，需要 TEARDOWN 后重新 SETUP。换配置不是给存活中的流改标签，而是一次旧状态退出、新传输与新密钥重新建立的连续性事件。

没有应答路径时，责任落回发起者

SAP、电子邮件或网页可以散发会话描述，却不提供互动协商。发起者必须给出可用替代，并保护安全参数的分发。RFC 4568 的 inline 密钥尤其说明问题：若承载描述的通道没有机密性，旁观者可以在媒体开始前获得密钥。之后使用 SRTCP 并不能挽回已暴露的材料。

后来 RFC 8866 取代了旧 SDP 文档，RFC 7826 取代了早期 RTSP 文档，RFC 5763 与 RFC 5764 形成了 DTLS-SRTP 规范背景。这些生命周期记录不能被写成 RFC 5124 已更新，也不能被写成当代部署证据。

RFC Editor 元数据把 RFC 5124 列为 2008 年 2 月的 Proposed Standard，没有列出更新或废止关系。IANA 注册表能证明参数已经协调分配。冻结来源没有提供某家厂商、现网比例、事故、互操作测试或用户质量数据，所以本文不虚构这些事实。

来源