WebRTC 是否为提议者加密来自提议 SDP 的数据并为应答者回答 SDP？

如何解决WebRTC 是否为提议者加密来自提议 SDP 的数据并为应答者回答 SDP？

在 WebRTC 通话期间，提议者和回答者分别共享提议和回答 SDP。
我想对等方将使用来自各自 SDP 的一些信息（如指纹等）来加密数据，以便其他对等方可以解密和消费媒体流。

是不是像：提议者在“提议 SDP”中有那些加密解密信息，而应答者在“应答 SDP”中有这些信息？

---

这样做的目的是为 Selective Forwarding Unit (SFU) 尝试一种可能的实现，其中用户只上传一次流。现在，他们的报价 SDP 与少量初始信令字节一起存储在服务器中的某处。无论哪个对等方想要使用该流，都将共享相同的报价并且它应该可以工作，因为加密-解密密钥将是报价 SDP 的一部分。

这个问题与为以下问题寻找可能的解决方案的努力有关：
Is there any alternative approach to implement WebRTC SFU,to have only 1 upload stream?

解决方法

WebRTC 中的加密是使用 DTLS（或 DTLS-SRTP）完成的。这意味着加密密钥（双向）是通过连接的前几个 UDP 数据包在对等方之间协商的。

此加密使用自签名证书，您可以在 SDP 的 a=fingerprint: 行中找到其指纹，并对此进行验证。

当将媒体数据包转发到另一个客户端时，SFU 需要解密和重新加密。

,

所有 WebRTC 流量（媒体轨道、数据通道）都使用在 SDP 交换（提供/回答）期间协商的密钥进行身份验证和加密。交换是无懈可击的窃听：如果攻击者能够收到报价/答案交换的副本，他们将无法拦截 WebRTC 流量。另一方面，交换容易受到中间人攻击：如果攻击者能够修改提议/答案交换，他们可能能够窃听和欺骗媒体流量。

因此，offer/answer 交换不需要加密，但需要进行身份验证。执行交换的最常见方法是使用受 TLS 保护的通道（例如 https 或基于 TLS 的 WebSocket），但这不一定对客户端进行身份验证。如果需要更高的安全性，可以使用其他解决方案；例如，使用 crypto.subtle API 通过共享密钥对 SDP 进行身份验证非常容易。