1. 简介

Internet 从其生命周期的很早期开始, 就被认为可能成为部署实时交互式应用的载体. 最容易想象的应用包括音频会话, 也称为 "Internet telephony", 以及视频会议. 早期构建此类应用的尝试依赖专用网络, 专用硬件和定制软件, 往往价格很高或质量较低, 并对基础设施提出很高要求.

随着可用带宽增加, 处理器和其他硬件不断变快, 参与门槛已经降低, 在普遍可用的计算硬件上提供令人满意的体验已经成为可能. 但是, 实现普遍通信仍存在若干障碍. 其中一个障碍是, 到目前为止, 还没有一组所有人都同意应当用于通信的统一通信协议. 另一个障碍是缺乏通用标识系统, 例如其他通信系统中由电话号码或电子邮件地址提供的标识能力.

然而, "The Universal Solution" 的开发已经证明非常困难. 过去几年还出现了一个用于部署服务的新平台: 嵌入浏览器的应用, 或称 "web application". 事实证明, 只要浏览器平台具备必要接口, 几乎任何类型的服务都可以在其上交付. 传统上, 这些接口由插件提供, 插件必须独立于浏览器下载和安装. 在 HTML5 [HTML5] 的发展过程中, 应用开发者对以标准化方式在浏览器内提供这些接口的可能性寄予厚望.

本文描述一组构建块, 它们 (1) 可以通过浏览器中的 JavaScript API 访问和控制, 并且 (2) 合在一起形成一组足够的功能, 允许应用在 Internet 上直接通过浏览器之间的通信使用交互式音频和视频. 由此形成的协议套件旨在支持 WebRTC "use cases" 文档 [RFC7478] 中列为必需场景的所有应用.

其他工作, 例如 W3C Web Real-Time Communications, Web Applications Security, 以及 Devices and Sensors Working Groups, 侧重于在 HTML5 工作之内或旁边, 为这些功能提供标准化 API 和接口. 本文则集中于规定为了定义网络交互所需的协议和子协议.

运营者应注意, 部署 WebRTC 将改变网络上实时媒体信令的性质, 也可能导致用于创建和消费此类媒体的设备类型发生变化. 就信令而言, WebRTC 会话建立通常会通过受 TLS 保护的 Web 技术完成, 并使用特定于应用的协议.

涉及插入网络元素来解释 Session Description Protocol (SDP) 的运维技术将无法用于此类信令. 这类技术包括 (1) 端点向网络请求 SIP 服务器 [RFC3361], 或 (2) 透明插入 SIP Application Layer Gateways (ALGs). 对于使用协作端点的网络, [RFC8155] 中定义的方法可以作为 [RFC3361] 的适当替代方案.

基于浏览器的通信增加, 也可能导致通信从专用实时通信硬件, 例如 SIP 桌面电话, 转向其他设备. 这会削弱某些运维技术的效果, 例如为了应用流量过滤和 QoS 而把专用实时设备放在独立网络段, 地址范围或 VLAN 中. 应用 [RFC8837] 中描述的标记可能是此类技术的适当替代方式.

虽然本文在形式上依赖 [RFC8445], 但在本文发布时, 大多数 WebRTC 实现支持的是 [RFC5245] 中描述的 Interactive Connectivity Establishment (ICE) 版本, 并使用 [RFC8838] 中描述的 Trickle ICE 机制的预标准版本. [RFC8445] 中定义的 "ice2" 属性可用于检测远端端点正在使用的版本, 并提供从旧规范平滑迁移到新规范的方式.

本文使用术语 "WebRTC" (注意大小写) 指代由 IETF 和 W3C 两方面工作共同组成的整体工作.