2. Principles and Terminology (原则与术语)

2.1. Goals of This Document (本文档的目标)

WebRTC 协议规范的目标是规定一组协议，如果全部实现，将允许一个实现使用音频、视频和数据与另一个实现进行通信，这些数据沿着参与者之间最直接的可能路径发送。

本文档旨在作为 WebRTC 规范的路线图 (Roadmap)。它定义了 WebRTC 协议规范其他部分使用的术语，列出了在 WebRTC 上下文中不需要进一步阐述的其他规范的参考，并提供了构成 WebRTC 套件一部分的其他文档的指针。

通过阅读本文档及其引用的文档，应该可以获得实现 WebRTC 兼容实现所需的所有信息。

2.2. Relationship between API and Protocol (API 与协议之间的关系)

整个 WebRTC 工作由两个主要部分组成，每个部分由多个文档组成:

• 协议规范 (Protocol Specification)，在 IETF 中完成

• JavaScript API 规范，在一系列 W3C 文档 [W3C.WD-webrtc] [W3C.WD-mediacapture-streams] 中定义

这两个规范共同旨在提供一个环境，在该环境中，嵌入在任何页面中的 JavaScript，当得到其用户的适当授权时，能够使用音频、视频和辅助数据建立通信，只要浏览器支持这些规范。浏览器环境不限制可以使用此功能的应用类型。

协议规范不假设所有实现都实现此 API；互操作不需要知道与之通信的实体是浏览器还是实现协议规范的另一个设备。

协议规范和 API 规范之间协作的目标是，对于协议规范的所有选项和特性，应该清楚要进行哪些 API 调用来使用该选项或特性；类似地，对于任何 API 调用序列，应该清楚将调用哪些协议选项和特性。当然，两者都受到实现约束的限制。

以下术语在规定 WebRTC 套件的文档中使用，具有此处给出的特定含义。并非所有术语都在本文档中使用。其他术语按其常用含义使用。

Agent (代理): 未定义的术语。参见 "SDP Agent" 和 "ICE Agent"。

Application Programming Interface (API) (应用编程接口): 一组调用和事件的规范，通常与编程语言或抽象形式规范 (如 WebIDL) 绑定，具有其定义的语义。

Browser (浏览器): 与 [HTML5] 中定义的 "interactive user agent (交互式用户代理)" 同义使用。另请参见下面的 "WebRTC Browser (又名 "WebRTC User Agent")" 定义。

Data Channel (数据通道): 一种抽象，允许在 WebRTC 端点之间以消息形式发送数据。两个端点之间可以有多个数据通道。

ICE Agent (ICE 代理): 交互式连接建立 (Interactive Connectivity Establishment, ICE) 协议 [RFC8445] 的实现。ICE Agent 也可以是 SDP Agent，但存在不使用 SDP 的 ICE Agent (例如，使用 Jingle [XEP-0166] 的那些)。

Interactive (交互式): 多方之间的通信，其中期望一方的动作可以引起另一方的反应，并且第一方可以观察到该反应，其中动作/反应/观察所需的总时间不超过数百毫秒的量级。

Media (媒体): 音频和视频内容。不要与 "transmission media (传输媒介)" (如电线) 混淆。

Media Path (媒体路径): 媒体数据从一个 WebRTC 端点到另一个端点所遵循的路径。

Protocol (协议): 一组数据单元、其表示以及其传输规则的规范，具有其定义的语义。协议通常被认为是在系统之间进行的。

Real-Time Media (实时媒体): 内容的生成和显示旨在在时间上紧密地发生 (不超过数百毫秒的量级) 的媒体。实时媒体可用于支持交互式通信。

SDP Agent (SDP 代理): 参与会话描述协议 (Session Description Protocol, SDP) offer/answer 交换的协议实现，如 [RFC3264] 第 3 节中所定义。

Signaling (信令): 为了建立、管理和控制媒体路径和数据路径而发生的通信。

Signaling Path (信令路径): 参与信令的实体之间用于传输信令的通信通道。信令路径中的实体可能比媒体路径中的实体多。

WebRTC Browser (WebRTC 浏览器) (也称为 "WebRTC User Agent" 或 "WebRTC UA"): 符合上述协议规范和 JavaScript API 的东西。

WebRTC Non-Browser (WebRTC 非浏览器): 符合协议规范但不声称实现 JavaScript API 的东西。这也可以称为 "WebRTC device (WebRTC 设备)" 或 "WebRTC native application (WebRTC 原生应用)"。

WebRTC Endpoint (WebRTC 端点): WebRTC 浏览器或 WebRTC 非浏览器。它符合协议规范。

WebRTC-Compatible Endpoint (WebRTC 兼容端点): 能够成功与 WebRTC 端点通信但可能无法满足 WebRTC 端点某些要求的端点。这可能会限制此类端点可以连接到网络中的位置，或者可能会限制它向其他人提供的安全保证。它不受本规范的约束；当提到它时，是为了注意对 WebRTC 端点提出的要求对 WebRTC 兼容端点的影响。

WebRTC Gateway (WebRTC 网关): 一个 WebRTC 兼容端点，它将媒体流量中介到非 WebRTC 实体。

所有 WebRTC 浏览器都是 WebRTC 端点，因此对 WebRTC 端点的任何要求也适用于 WebRTC 浏览器。

WebRTC 非浏览器可能能够以类似于浏览器托管 JavaScript 应用的方式托管应用，通常通过提供其他语言的 API。例如，它可以实现为提供 C++ API 的库，旨在加载到应用中。在这种情况下，可能需要类似于 JavaScript 的安全考虑；但是，由于此处未定义或引用此类 API，因此本文档无法为这些接口提供任何特定规则。

WebRTC 网关在单独的文档 [WebRTC-Gateways] 中描述。

2.3. On Interoperability and Innovation (关于互操作性与创新)

"IETF 的使命声明" [RFC3935] 指出："标准对互联网的好处在于互操作性 -- 实现标准的多个产品能够协同工作，以便为互联网用户提供有价值的功能。"

互联网上的通信经常分两个阶段进行:

• 两方通过某种机制进行通信，确定它们都能够支持什么功能。

• 它们使用该共享的通信功能进行通信，或者，如果找不到任何共同点，则放弃通信。

对于通信功能，通常可以做出许多选择；互联网的历史充满了各种协议中各种类型选项的提议、标准化、实现以及成功或失败。

拥有强制实现 (Mandatory-to-Implement) 功能集的目标是防止协商失败，而不是抢占或阻止协商。

强制实现功能集的存在是部署市场的强大改变者，因为它保证只要 (1) 您符合规范并且 (2) 另一方愿意接受该规范基本级别的通信，您就可以成功通信。

替代方案 (即，没有强制实现功能) 并不意味着您无法通信；它仅仅意味着为了成为通信伙伴关系的一部分，您必须实现标准 "以及其他一些东西"。这个 "以及其他一些东西" 通常被称为某种配置文件 (Profile)；在最违背互联网精神的版本中，这个 "以及其他一些东西" 包括必须仅使用特定供应商的产品。

2.4. Terminology (术语)

本文档中的关键词 "MUST (必须)"、"MUST NOT (禁止)"、"REQUIRED (必需)"、"SHALL (应)"、"SHALL NOT (不应)"、"SHOULD (应该)"、"SHOULD NOT (不应该)"、"RECOMMENDED (推荐)"、"NOT RECOMMENDED (不推荐)"、"MAY (可以)" 和 "OPTIONAL (可选)" 应按 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，当且仅当它们以全部大写形式出现时，如此处所示。

---