7. 连接管理

建立, 协商和拆除连接所需的方法, 机制和要求是一个很大的主题, 同时也是一个既需要互操作性, 又需要创新自由的领域. 以下原则适用:

1. WebRTC 媒体协商将能够表示 SIP 中使用的相同 SDP offer/answer 语义 [RFC3264], 从而可以在 SIP 与 WebRTC 媒体协商之间构建信令网关.

2. 对于支持 ICE 以及适当 RTP/SDP 机制, 编解码器和安全机制的传统 SIP 设备, 将可以在不使用媒体网关的情况下进行网关互通. 可能需要一个信令网关来在 Web 侧信令与 SIP 信令之间转换.

3. 当为新的编解码器指定 SDP 时, 不应再需要其他标准化工作, 才能让该编解码器在 Web 浏览器中使用. 添加可能带有新 SDP 参数的新编解码器, 不应改变浏览器与 JavaScript 应用之间的 API. 只要浏览器支持这些新编解码器, 在这些编解码器指定之前编写的旧应用就应能在适当情况下自动使用它们, 而无需修改 JavaScript 应用.

WebRTC 所做的具体选择, 以及这些选择对实现 WebRTC 的浏览器所提供 API 的影响, 在 [RFC8829] 中描述. WebRTC 浏览器 MUST 实现 [RFC8829].

WebRTC 端点 MUST 实现 [RFC8829] 中与网络层相关的功能, 例如 BUNDLE [RFC8843], "rtcp-mux" [RFC5761] 和 Trickle ICE [RFC8838]. 但这些端点不需要支持 [RFC8829] 中描述的 API 功能.