跳到主要内容

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] 中的说明解释.