我们首先回顾一下媒体加密如何与 SFU 等媒体服务器设备一起工作。

WebRTC中的媒体加密

WebRTC要求加密。它使用 DTLS-SRTP 对媒体进行加密。DTLS-SRTP 的工作原理是使用 DTLS 握手派生用于加密 RTP 数据包有效负载的密钥。它通过比较a=指纹SDP 中的行，通过信令服务器与握手中使用的自签名证书的指纹交换。这可以称为端到端加密，因为协商的密钥不会离开本地设备，并且浏览器无法访问它们。但是，如果没有身份验证，它仍然容易受到中间人攻击。

SFU 挑战

多方的主要体系结构是选择性转发单元 （SFU）。SFU 基本上是数据包路由器，将单个或一小组流从一个用户转发到许多其他用户。

在加密方面，DTLS-SRTP 协商发生在每个对等端点和 SFU 之间。这意味着 SFU 可以访问未加密的有效负载并可以侦听。这对于服务器端录制等功能是必需的。不利的一面是，这意味着您需要信任运行 SFU 和/或客户端代码的实体以保持该流的私密性。零信任始终是保护隐私的最佳选择。

与解码和混合媒体的更传统的VoIP多点控制单元（MCU）不同，SFU仅路由数据包。它不太关心内容（除了标头中的字节数以及帧是否是关键帧）。因此，从理论上讲，SFU 不需要解码和解密任何东西。SFU开发人员从WebRTC的早期就已经意识到了这个问题。同样，谷歌的 webrtc.org 库已经包含了一段时间的“帧加密”方法，这可能是为Google Duo添加的，但在浏览器中不存在。然而，普遍解决这个问题的“正确”API现在只发生在WebRTC Insertable Streams。

可插入流迭代帧，而不是数据包

WebRTC Insertable Streams目前包含两项内容：

• Encoded Transform：操作编码后的数据以及解码前数据（Post-encoding/Pre-decoding）
• Mediacapture Transform：操作编码前数据以及解码后数据（Pre-encoding /Post-decoding）

WebRTC Insertable Streams这项新特性增加了些新API，让Web开发者对媒体数据可以做如下的事：

• • 允许用户不打破WebRTC正常处理pipeline，手动处理数据

• 允许使用WASM技术进行数据处理
• 允许使用Web Worker技术处理数据，避免阻塞主线程
• 允许端到端间进行数据加解密，避免安全以及隐私泄露风险（不信任SFU服务器，避免中间人攻击）

Insertable Streams API 在编码器/解码器和将帧拆分为 RTP 数据包的数据包器之间运行。它可以转换编码的帧。加密是这种转换的一个例子。

与每个数据包相比，在帧级别操作具有另一个优势：不必担心加密增加了多少字节的开销。数据包器负责吐出数据包。除此之外，它还可以轻松传递元数据，例如（对于视频帧）帧是关键帧还是增量帧。

整体上看，Insertable Streams API提供了为WebRTC应用程序实施端到端加密的能力，使用 TransformStream 的总体设计是可靠的，对于真正应用的场景来说，加密和密钥管理这部分需要更多的努力。