安全通话不止有一条数据路径。信令负责协调谁在呼叫以及端点如何连接；媒体路径则承载音频和视频。保护一条路径不会自动保护另一条，而且单独保护任何一条都无法隐藏所有通信模式。
WebRTC 提供了重要的安全机制，但应用的身份检查、服务器角色和录制模式仍然决定着完整的隐私边界。
信令与媒体承担不同任务
| 层 | 典型用途 | 安全问题 |
|---|---|---|
| 信令 | 邀请、会话描述和连接候选信息 | 谁能读取或修改建立连接的信息，如何验证预期对端的身份？ |
| 媒体 | 音频、视频及相关实时流 | 加密在哪一端终止，哪些端点可以访问媒体？ |
| 运行记录 | 路由、连接时间和投递状态 | 服务或网络能够观察到哪些元数据？ |
| 录制 | 生成保留的副本 | 谁会获得明文或可用的录制密钥，副本存储在哪里？ |
消息协议可以承载加密信令，但 WebRTC 并不普遍要求使用某款通信软件的封装格式。其他经过身份验证的设计也可行。
DTLS-SRTP 提供什么
WebRTC 安全架构 RFC 8827要求保护媒体通道，并描述了 DTLS-SRTP 密钥建立过程。简单来说，DTLS 帮助建立密码学上下文，SRTP 则保护实时媒体数据包。
这种保护的端点很重要。参与者之间的直接加密连接，与在媒体处理服务器处终止的连接不同。有些多方系统会在面向服务器的传输加密之上增加独立的端到端层。仅凭“WebRTC”这个词，无法判断产品采用哪种架构。
为什么信令身份验证很重要
通话建立信息中可能包含用于将媒体连接绑定到预期对方的信息。如果攻击者能够替换这些信息而不被发现，加密就可能建立一条通向错误端点的受保护连接。
RFC 8827 讨论了信令、身份和 DTLS 指纹之间的这种关系。HTTPS 保护的是到信令服务的连接；它本身并不能免除对恶意或遭入侵服务的考虑。经过端到端身份验证的信令，或适当的独立对端验证机制，可以增强这道边界。
信令保密是一个相关但不同的目标：它限制谁能够读取建立连接的细节。设计应同时解释保密性和身份验证，而不是将一块加密数据视为两者都已实现的充分证据。
加密信令不会让通话隐形
中继仍可能知道它正在为哪些账户或设备之间的通信进行路由。网络观察者可能看到连接时间、流量大小和服务器地址。根据连接设计，对端或中继基础设施也可能获知网络信息。
因此，加密通话邀请并不能证明服务无法推断通话、绘制关系图或保留通话相关记录。隐藏内容与隐藏流量模式是不同的问题。
Livara 公开说明的边界
Livara 的安全页面将直接通话和群组通话描述为端到端加密，但明确说明可选的服务器录制是一个例外：当可见的 REC 状态处于开启状态时，通话使用传输加密，而不是 E2EE。
其威胁模型也不承诺元数据匿名性，或防御已遭入侵的设备。这些是产品方面的说明，并非对每条通话路径的独立验证。本指南不声称任何未经核实的参与人数上限、信令格式或后量子媒体实现。
尤其是，通信软件采用后量子密钥交换，并不会自动升级独立的 WebRTC 媒体握手。媒体路径上的算法和密钥绑定必须单独评估。
敏感通话之前
- 确认参与者，并检查意外的身份变化。
- 检查录制是否开启，以及应用说明这会改变什么。
- 了解服务是处理媒体，还是仅转发受保护的数据包。
- 考虑参与者周围的设备和房间：恶意软件、屏幕捕获或附近的旁听者，都可能在解密后泄露内容。
- 索取针对你所使用的具体模式的架构和测试证据，而不是依赖笼统的“加密通话”标识。
有用的安全声明会分别指出谁能访问信令、媒体、元数据和录制内容。
