2. 原则与术语

2.1. 本文档的目标

WebRTC 协议规范的目标是规定一组协议. 如果这些协议都已实现, 一个实现就能够使用音频, 视频和数据与另一个实现通信, 且这些数据会沿参与者之间尽可能直接的路径发送.

本文旨在作为 WebRTC 规范的路线图. 它定义 WebRTC 协议规范其他部分所使用的术语, 列出在 WebRTC 语境中无需进一步展开的其他规范引用, 并指向构成 WebRTC 套件一部分的其他文档.

通过阅读本文及其引用的文档, 应当能够获得实现一个 WebRTC-compatible implementation 所需的全部信息.

2.2. API 与协议之间的关系

整个 WebRTC 工作由两个主要部分组成, 每个部分都包含多个文档:

• 在 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 endpoints 之间发送数据. 两个端点之间可以有多个 data channels.

ICE Agent: : Interactive Connectivity Establishment (ICE) 协议 [RFC8445] 的实现. ICE Agent 也可以是 SDP Agent, 但也存在不使用 SDP 的 ICE Agents, 例如使用 Jingle [XEP-0166] 的实现.

Interactive: : 多方之间的通信, 其中预期一方的动作可以引发另一方的反应, 且第一方可以观察到该反应, 动作/反应/观察所需总时间大致不超过数百毫秒.

Media: : 音频和视频内容. 不要与线缆等 "transmission media" 混淆.

Media Path: : 媒体数据从一个 WebRTC endpoint 到另一个 WebRTC endpoint 所经过的路径.

Protocol: : 对一组数据单元, 其表示方式以及传输规则的规范, 并具有其定义的语义. 通常认为协议运行在系统之间.

Real-Time Media: : 内容的生成和显示预期在时间上紧密相邻的媒体, 大致不超过数百毫秒. 实时媒体可用于支持交互式通信.

SDP Agent: : 参与 Session Description Protocol (SDP) offer/answer 交换的协议实现, 如 [RFC3264] Section 3 所定义.

Signaling: : 为建立, 管理和控制 media paths 与 data paths 而发生的通信.

Signaling Path: : 参与信令的实体之间用于传递信令的通信信道. Signaling path 中的实体数量可能多于 media path 中的实体数量.

WebRTC Browser (也称为 "WebRTC User Agent" 或 "WebRTC UA"): : 同时符合上述协议规范和 JavaScript API 的实体.

WebRTC Non-Browser: : 符合协议规范, 但不声称实现 JavaScript API 的实体. 它也可以称为 "WebRTC device" 或 "WebRTC native application".

WebRTC Endpoint: : WebRTC browser 或 WebRTC non-browser. 它符合协议规范.

WebRTC-Compatible Endpoint: : 能够与 WebRTC endpoint 成功通信, 但可能无法满足 WebRTC endpoint 的某些要求的端点. 这可能限制此类端点可连接到网络中的位置, 或限制它向其他方提供的安全保证. 它不受本规范约束. 当本文提及它时, 只是为了说明施加于 WebRTC endpoints 的要求对 WebRTC-compatible endpoints 的影响.

WebRTC Gateway: : 一种 WebRTC-compatible endpoint, 它为非 WebRTC 实体中介媒体流量.

所有 WebRTC browsers 都是 WebRTC endpoints, 因此对 WebRTC endpoint 的任何要求也适用于 WebRTC browser. WebRTC non-browser 可能能够以类似浏览器托管 JavaScript 应用的方式托管应用, 通常是通过提供其他语言的 API. 例如, 它可以实现为一个库, 提供意在加载到应用中的 C++ API.

在这种情况下, 可能需要与 JavaScript 类似的安全考虑. 但是, 由于这里既没有定义也没有引用此类 API, 本文无法为这些接口给出任何具体规则. WebRTC gateways 在单独文档 [WebRTC-Gateways] 中描述.

2.3. 关于互操作性与创新

"Mission statement for the IETF" [RFC3935] 指出, "The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users."

Internet 上的通信经常分两个阶段发生:

• 两方通过某种机制沟通它们都能够支持哪些功能.
• 它们使用这种共同的通信功能进行通信, 或者如果找不到任何共同点, 就放弃通信.

对于通信功能, 通常可以有许多选择. Internet 的历史充满了各种协议中许多类型选项的提出, 标准化, 实现, 成功或失败. 拥有 mandatory-to-implement 功能集的目标是防止协商失败, 而不是抢占或阻止协商.

mandatory-to-implement 功能集的存在会强烈改变部署市场, 因为它提供了一种保证: 只要 (1) 你符合某个规范, 并且 (2) 对方愿意按该规范的基础级别接受通信, 你就可以成功通信.

另一种情况, 即没有 mandatory-to-implement 功能, 并不意味着你无法通信. 它只是意味着为了成为通信伙伴关系的一部分, 你必须实现该标准 "and then some". 这种 "and then some" 通常称为某种 profile. 在与 Internet 精神最相悖的版本中, 这种 "and then some" 意味着只能使用某个特定厂商的产品.

2.4. 术语

本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在以这里所示的全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的说明解释.