6. Miscellaneous Considerations (其他考虑)
6.1. Anonymous Calls (匿名呼叫)
使用 DTLS-SRTP 并不提供匿名呼叫能力, 但也不阻止匿名呼叫. 然而, 在使用 [RFC3325] 或 [RFC5767] 等匿名呼叫特性时若不加注意, DTLS-SRTP 可能使原本匿名的呼叫被去匿名化. 进行匿名呼叫时, 应当 (SHOULD) 采用以下程序以防去匿名化.
进行匿名呼叫时, 每次呼叫应当 (SHOULD) 使用新的自签名证书, 以免将多次呼叫关联到同一主叫. 若可接受一定程度的关联, 为支持认证连续性 (见第 8.4 节), 若干次呼叫应当 (SHOULD) 使用同一证书.
此外, 在部署 [RFC3325] 的网络中, RFC 3325 要求将 [RFC3323] 定义的 Privacy 头字段值设为 id. 这与 SIP 身份机制配合, 确保启用匿名呼叫时不断言用户身份. 此外, 证书内 subjectAltName 属性的内容禁止 (MUST NOT) 包含可关联或可识别希望发起匿名呼叫用户的信息. 注意: 仅遵循本建议并不足以提供匿名化.
6.2. Early Media (早期媒体)
若某端点希望提供早期媒体并收到 offer, 它必须 (MUST) 承担 setup:active 角色, 并可立即与对端建立 DTLS 关联并开始发送媒体. setup:passive 端点可能尚未验证 active 端点证书的指纹. 该情况下媒体处理的安全方面见第 8 节.
6.3. Forking (分叉)
在 SIP 中, 请求可能分叉到多个端点. 每个分叉请求可能产生不同 answer. 假定请求方提供了 offer, 每个 answerer 将提供唯一 answer. 每个 answerer 与 offerer 形成一个 DTLS 关联. offerer 随后可通过将 answer 中的指纹与各 DTLS 关联的证书哈希比较, 将 SIP 消息中收到的 SDP answer 安全地对应起来.
6.4. Delayed Offer Calls (延迟 offer 呼叫)
端点可发送不含 offer 的 SIP INVITE. 此时 INVITE 的接收方在响应中提供 offer, 发起方在随后的 ACK 或 (若双方均支持可靠临时响应) PRACK 请求 [RFC3262] 中提供 answer. 无论何种情况, active 端点仍按 offer/answer 协商结果与 passive 端点建立 DTLS 关联.
6.5. Multiple Associations (多个关联)
存在多条流时 (例如多条媒体流, 未复用的 RTP 与 RTCP 等), active 侧可以 (MAY) 按任意顺序执行 DTLS 握手. [RFC5764] 附录 B 对并行 DTLS 握手有所说明. 注意: 若最终由 answerer 作为 active, 它可能仅在部分潜在流上发起握手 (例如同时提供音频与视频但只希望使用音频). 若由 offerer 作为 active, 则在开始发起握手前会收到完整 answer.
6.6. Session Modification (会话修改)
一旦向 offerer 提供了 answer, 任一端点可以 (MAY) 请求会话修改, 其中可包含 (MAY) 更新的 offer. 会话修改可承载于 INVITE 或 UPDATE 请求. 若现有关联兼容 (即密钥指纹与传输参数相同), 对等方可复用; 否则按与初始交换相同的规则建立新关联, 并在 offer/answer 交换完成后拆除旧关联. 注意: 若端点 active/passive 角色发生变化, 必须 (MUST) 建立新连接.
6.7. Middlebox Interaction (中间盒交互)
DTLS-SRTP 与中间盒之间可能存在多种不良交互, 见 [MMUSIC-MEDIA], 该文档也给出了避免问题的建议.
6.7.1. ICE Interaction (ICE 交互)
交互式连接建立 (Interactive Connectivity Establishment, ICE) [RFC5245] 提供了一种使多媒体会话参与方验证互通性的方法. 使用 ICE 时, 在 DTLS 握手开始前执行 ICE 连通性检查. 注意: 若使用激进提名 (aggressive nomination) 模式, 在 ICE 最终收敛到单一候选对之前, 可能有多对候选被标记为有效. 实现必须 (MUST) 将属于同一组件的所有 ICE 候选对视为同一 DTLS 关联的一部分. 因此即使存在多对有效候选, 也仅进行一次 DTLS 握手. 注意: 若所选候选对发生变化, 可能需要调整端点 IP 地址, 如同 DTLS 报文为普通媒体流一样.
注意: 通过 NAT 的 UDP 简单穿越 (Simple Traversal of the UDP Protocol through NAT, STUN) 报文直接在 UDP 上发送, 不经 DTLS. [RFC5764] 说明如何将 STUN 与 DTLS 及 SRTP 报文解复用.
6.7.2. Latching Control without ICE (不使用 ICE 时的锁定控制)
若未使用 ICE, 则可能通过 [MMUSIC-MEDIA] 所述的 "latching (锁定)" 与会话边界控制器 (Session Border Controllers, SBC) 产生不良交互. 为避免该问题, 若未使用 ICE 且在收到对方 SDP 时 DTLS 握手尚未完成, 则 passive 侧必须 (MUST) 执行一次未经认证的 STUN [RFC5389] 连通性检查以打开相应针孔. 所有实现必须 (MUST) 在握手期间准备好响应该请求, 即使平时不使用 ICE. 但是, active 侧必须 (MUST) 在适当情况下继续 DTLS 握手, 即使未收到此类 STUN 检查; passive 侧禁止 (MUST NOT) 在发送 ServerHello 之前等待 STUN 应答.
6.8. Rekeying (重密钥)
与 TLS 类似, DTLS 端点可随时通过重新进行 DTLS 握手来重密钥. 重密钥进行期间, 端点继续使用先前建立的密钥材料处理 DTLS. 新会话密钥建立后, 会话可切换到新密钥并放弃旧密钥. 从而避免重密钥过程引入时延.
使用 DTLS 建立 SRTP 安全上下文时关于重密钥的进一步说明见 [RFC5764] 第 3.7 节.
6.9. Conference Servers and Shared Encryptions Contexts (会议服务器与共享加密上下文)
曾有提议让会议服务器对会议中所有参与者使用同一加密上下文. 其优点是会议服务器只需为所有发言者加密输出一次, 而不必对每个参与者各加密一次.
在本规范下不可能采用该共享加密上下文方法, 因为每次 DTLS 握手都会建立双方均无法完全控制的新密钥. 不过, 与会议服务器执行的其他任务 (如编解码处理) 相比, 加密每个 RTP 报文的开销被认为很小.
未来扩展如 [SRTP-EKT] 或 [KEY-TRANSPORT] 可与本文档机制配合提供此类能力.
6.10. Media over SRTP (基于 SRTP 的媒体)
DTLS 的数据传输协议是通用的, 针对 RTP 的优化程度不如专为此设计的 SRTP [RFC3711]. DTLS-SRTP [RFC5764] 的定义使得可通过 DTLS 连接协商 SRTP 传输, 从而兼顾 SRTP 的性能优势与 DTLS 的简易密钥管理. 在某些环境中复用现有 SRTP 软硬件实现也可能是选择 DTLS-SRTP 而非 “RTP over DTLS” 的重要动机. 本规范的实现必须 (MUST) 支持 DTLS-SRTP [RFC5764].
6.11. Best Effort Encryption (尽力加密)
[RFC5479] 描述了尽力加密需求: 使用 SRTP, 且双方均支持并成功完成密钥协商时使用 SRTP, 否则使用 RTP.
[MMUSIC-SDP] 描述了一种可同时信令 RTP 与 SRTP 作为备选的机制. 这使 offerer 可表达对 SRTP 的偏好, 但默认仍为 RTP, 不理解 SRTP 或本密钥交换机制的端点仍可理解. 本文档的实现必须 (MUST) 支持 [MMUSIC-SDP].