1. Introduction (简介)

从互联网诞生之初，它就被认为是部署实时交互式应用的可能载体 -- 其中最容易想象的是音频对话 (即"互联网电话") 和视频会议。

最初构建此类应用的尝试依赖于特殊网络、特殊硬件和定制软件，通常价格非常高昂或质量低下，对基础设施提出了很高的要求。

随着可用带宽的增加，以及处理器和其他硬件变得越来越快，参与的障碍已经降低，现在可以在常见的计算硬件上提供令人满意的体验。

然而，仍然存在许多阻碍通用通信能力的障碍 -- 其中之一是，到目前为止，还没有一套所有人都同意应该用于通信的单一通信协议集；另一个障碍是完全缺乏通用的身份识别系统 (例如其他通信系统中的电话号码或电子邮件地址)。

然而，开发"通用解决方案"已被证明是困难的。

过去几年还见证了一个新平台的兴起用于服务部署: 浏览器嵌入式应用 (Browser-Embedded Application)，或称"Web 应用 (Web Application)"。事实证明，只要浏览器平台具有必要的接口，就可以在其上提供几乎任何类型的服务。

传统上，这些接口是通过插件 (Plugins) 提供的，这些插件必须与浏览器分开下载和安装；在 HTML5 [HTML5] 的开发中，应用开发者看到了在浏览器内以标准化方式提供这些接口的巨大前景。

本备忘录描述了一组构建块 (Building Blocks)，这些构建块 (1) 可以通过浏览器中的 JavaScript API 进行访问和控制，(2) 共同构成一组足够的功能，允许在通过互联网直接在浏览器之间通信的应用中使用交互式音频和视频。由此产生的协议套件旨在实现 WebRTC "用例" 文档 [RFC7478] 中描述的所有必需场景的应用。

其他工作 -- 例如，W3C Web 实时通信 (Web Real-Time Communications)、Web 应用安全 (Web Applications Security) 和设备与传感器 (Devices and Sensors) 工作组 -- 专注于在 HTML5 工作的范围内或与之并行，为这些功能提供标准化的 API 和接口。本备忘录专注于规范网络交互所需的协议和子协议。

运营商应注意，WebRTC 的部署将导致网络上实时媒体信令性质的变化，并可能导致用于创建和消费此类媒体的设备类型的转变。在信令方面，WebRTC 会话建立通常会通过使用应用特定协议的 TLS 安全的 Web 技术进行。涉及插入网络元素来解释会话描述协议 (Session Description Protocol, SDP) 的操作技术 -- 无论是通过 (1) 端点向网络请求 SIP 服务器 [RFC3361] 还是 (2) 透明插入 SIP 应用层网关 (Application Layer Gateways, ALGs) -- 都不适用于此类信令。对于使用协作端点的网络，[RFC8155] 中定义的方法可以作为 [RFC3361] 的合适替代方案。基于浏览器的通信的增加也可能导致从专用实时通信硬件 (如 SIP 桌面电话) 的转变。这将降低将专用实时设备放置在其自己的网络段、地址范围或 VLAN 上以应用流量过滤和 QoS 等目的的操作技术的有效性。应用 [RFC8837] 中描述的标记可能是此类技术的适当替代方案。

虽然本文档正式依赖于 [RFC8445]，但在其发布时，大多数 WebRTC 实现支持 [RFC5245] 中描述的交互式连接建立 (Interactive Connectivity Establishment, ICE) 版本，并使用 [RFC8838] 中描述的 Trickle ICE 机制的预标准版本。[RFC8445] 中定义的 "ice2" 属性可用于检测远程端点使用的版本，并提供从旧规范到新规范的平滑过渡。