摘要

  • 中继不必读取音视频明文，也能选择给不同接收者转发哪些流、哪些编码版本和哪些质量层。
  • 收到密钥、解密成功与画面可解码并非同一状态。关键帧与密钥走不同路径，可能让入会者错过后续画面依赖的参考。
  • 加密的价值不应被低估，也不应被扩大为交付承诺。运行验收需要观察每个接收者的有效参与，而非只看连接和安全标志。

视频会议里的大窗口和角落里的一排小画面，往往不需要同样的传输资源。把所有人的最高质量视频都发给每个终端，未必是最好的服务方式；接收端的网络和解码能力也不允许运营者永远这样做。于是，选择本身成为会议系统的日常工作。

问题在于：当服务商承诺自己无法读取会议内容时，这份选择权去了哪里？

SFrame 的答案不是“选择权已经消失”。RFC 9605允许选择转发单元，即 SFU，在无法取得媒体解密所需密钥的条件下，继续完成转发工作。它把内容访问与中间节点的媒体调度分开。理解这项设计，不能只问中继是否看得见，还要问它仍然能决定什么。

省下来的带宽，来自具体的取舍

RFC 7667 第 3.7 节描述的选择转发架构，可以面向不同接收者提供不同的媒体子集。中继根据传输条件、显示布局等需要，选择源或可用的质量版本。这不是端到端加密的漏洞，而是该架构能够服务多方会议的重要原因。

差异交付因此不能自动等同于不当干预。一个缩略窗口获得较低质量画面，可能正是合理适配；弱网终端少收一些流，也可能因此保住主要发言人的声音和画面。真正需要交代的是选择依据、适用条件和恢复路径，而不是把“一律相同”当成正确性的唯一标准。

中继甚至可能影响控制反馈怎样继续传递。RFC 7667 说明，中间节点可以在本地处理 RTCP 请求，也可以把请求转向媒体源所在的一段连接。接收者需要一个新参考画面，并不意味着一条指令必然直接抵达发送者。请求如何处理、发送者何时响应、响应是否被选中转发，存在不同责任点。

加密并非把视频封成一个不可选择的整体

SFrame 的媒体处理细节说明，选择权也受具体结构约束。

采用联播编码时，发送者为同一视频生成多个编码版本，各版本分别形成密文，每次加密使用不同计数器值。SFU 可以在这些版本之间取舍，而无须看到里面的像素。采用可伸缩视频编码时，如果希望 SFU 能移除某一层，该层就必须位于独立的 SFrame 密文中。否则，中继不能随意裁切受保护内容，再指望完整性验证照常通过。

这里有两种不同的约束。发送端及应用决定哪些受保护单元可以独立选择；中继在这些单元中执行转发选择。认证保护限制对受保护数据的未被发现的修改，却不要求每一个有效单元都交付给每一个人。

因此，“中继不能改内容”与“中继不能影响观看结果”不可互换。前者可以是一项切实的安全收益，后者却忽略了发送哪些内容、发送什么质量以及接收者何时拿到可用材料这些操作。

元数据也处在这条边界上。SFrame 的密钥标识符和计数器受到完整性保护，但对相关中间节点并不保密。应用还可以把一定元数据纳入附加认证数据，使中继能读而不能不留痕迹地改动；不能反过来假定应用周围的全部元数据都自动得到这种保护。

这要求设计者克制地赋予标识符含义。若把不必要的业务语义塞入中继可见的密钥标识符，媒体加密不会顺便把这些含义藏起来。接收端也不能因为看得见元数据，就在认证成功前据此作语义处理；规范保留的是为准备解密而必需的例外。

入会成功后，为什么还可能没有可用画面

RFC 9605 第 6.2 节给出一个比“连接正常”更细的故障边界：成员变化时，密钥分发和媒体传输可以走不同路径。

假设新成员所需的关键帧已经发出，但接收者尚未拿到对应密钥。如果该关键帧被丢弃，随后拿到密钥并不能补回已经错过的参考。此后到达的依赖帧可能解密成功，却仍然无法解码。这里的“成功”与“失败”分别属于不同环节，并不矛盾。

规范讨论了在新密钥投入使用后再生成关键帧，以避免这种特定的参考缺失。它没有承诺所有实现都能在某个统一时间内显示首帧。对未知密钥的密文进行缓存重试，也只是规范允许的选择，不能当成所有产品已经具备的行为。本文描述的是标准明确考虑的机制，不是任何厂商发生过的实际事故。

加密粒度还会改变等待发生的位置。如果整个视频帧作为一个 SFrame 保护单元，接收端必须等完整受保护帧到齐并完成解密，才能解码；不能在该安排下提前做部分帧解码。按包处理则有另一组开销与集成取舍。不能仅凭这一区别，就宣称某种方案在所有网络和终端上更快。

这也解释了为什么只统计成功解密的帧会漏掉问题。它证明收到的对象通过了某一环节，却无法证明之前的参考对象已经到达，也无法证明正确的视频源被选中，或本机有足够资源完成显示。

安全承诺需要准确，而不是越大越好

SFrame 对传输流复用还有一个提醒：SSRC 或 MID 等标识符所承载的媒体来源可能随时间变化，并不天然等于屏幕上某个人的永久身份。经过认证的密钥标识符有助于抵御 SFU 对媒体归属的干扰，但对持有相应密钥的恶意会议参与者，SFrame 的对称机制并不提供个体发送者认证。这个限制不能被拿来抹去它对中继的保护价值，也不应被一个安全图标遮过去。

更外层的信任同样存在。RFC 8827把浏览器视为 WebRTC 的可信计算基础，并规定加密媒体传输的基本要求。增加 SFrame 不等于证明终端没有被控制，也不等于所有调用服务和端点关系都具有同一条信任边界。

资料本身也经过勘误核对。RFC 9605 官方勘误页在本次核查时列出三条已验证修正，分别涉及随机数构造伪代码中的变量、AES-CTR 非认证模式的表述，以及认证子密钥的说明。它们不取消本文讨论的媒体选择与关键帧衔接问题。规范与勘误是机制证据，不是部署普及率、实际延迟或蓄意阻断的证据。

保密边界缩小了中继的能力范围，但并没有把会议服务变成不需要运营判断的机器。把剩余能力讲清楚，恰恰有助于保住已经获得的安全收益。