3. Motivation (动机)

尽管该领域已有前期工作 (例如 SDP 的安全描述 [RFC4568], 与用于认证和密钥交换的 MIKEY [RFC3830] 结合的密钥管理扩展 [RFC4567]), 本规范动机如下:

• TLS 将用于面向连接媒体的安全. TLS 设计广为人知, 实现普遍可用.

• 本方法可在不要求支持可靠临时响应确认 (PRACK) [RFC3262] 的情况下处理分叉 (forking) 与早期媒体, 同时保留允许 offerer 选择用于加密媒体的密钥材料这一重要安全属性.

• 媒体路径的安全保护也在媒体路径上建立, 而非仅在信令路径上. 在许多部署场景中, 信令与媒体在网络中走不同路径.

• 使用 RFC 4474 时, 即使认证服务下游的 SIP 代理不可信, 本方案仍可行. 不必在 SIP 信令或 SDP 消息交换中泄露密钥, 这与 SDESCRIPTIONS [RFC4568] 不同. 对建立对话的请求进行重定向 (更改 Request-URI 的值) 时, 接收该请求的用户代理 (User Agent, UA), 即用户代理服务器 (User Agent Server, UAS), 其身份可能与 To 头字段中的身份不同. 使用 RFC 4916 时, 可以通过反方向请求向对等 UA 提供其身份, 并由认证服务对该身份签名.

• 在本方法中, 同步源 (synchronization source, SSRC) 冲突不会导致额外 SIP 信令.

• 许多 SIP 端点已实现 TLS. 即便使用 DTLS-SRTP [RFC5764], 对现有 SIP 与 RTP 用法的改动也很小.