跳到主要内容

3. 架构与功能组

对于基于浏览器的应用, 实时支持模型并不假定浏览器会包含电话或视频会议这类应用所需的所有功能. 设想是浏览器具备 Web 应用所需的功能, 并与其后端服务器配合来实现这些功能.

这意味着需要规定两个关键接口: 浏览器在没有任何中间服务器介入时用于彼此通信的协议, 以及提供给 JavaScript 应用以利用浏览器功能的 API.

                    +------------------------+  On-the-wire
                    |                        |  Protocols
                    |      Servers           |--------->
                    |                        |
                    |                        |
                    +------------------------+
                                ^
                                |
                                |
                                | HTTPS/
                                | WebSockets
                                |
                                |
                  +----------------------------+
                  |    JavaScript/HTML/CSS     |
                  +----------------------------+
               Other  ^                 ^ RTC
               APIs   |                 | APIs
                  +---|-----------------|------+
                  |   |                 |      |
                  |                 +---------+|
                  |                 | Browser ||  On-the-wire
                  | Browser         | RTC     ||  Protocols
                  |                 | Function|----------->
                  |                 |         ||
                  |                 |         ||
                  |                 +---------+|
                  +---------------------|------+
                                        |
                                        V
                                   Native OS Services

Figure 1: Browser Model

注意, HTTPS 和 WebSockets 也通过浏览器 API 提供给 JavaScript 应用.

与所有协议和 API 规范一样, 并不存在协议只能用于与另一个浏览器通信的限制. 由于这些协议已被完整规定, 任何忠实实现这些协议的端点都应能够与浏览器中运行的应用互操作. Figure 2 展示了一种常见的部署模型. ("JS" 表示 JavaScript.)

          +-----------+                  +-----------+
          |   Web     |                  |   Web     |
          |           |                  |           |
          |           |------------------|           |
          |  Server   |  Signaling Path  |  Server   |
          |           |                  |           |
          +-----------+                  +-----------+
               /                                \
              /                                  \ Application-defined
             /                                    \ over
            /                                      \ HTTPS/WebSockets
           /  Application-defined over              \
          /   HTTPS/WebSockets                       \
         /                                            \
   +-----------+                                +-----------+
   |JS/HTML/CSS|                                |JS/HTML/CSS|
   +-----------+                                +-----------+
   +-----------+                                +-----------+
   |           |                                |           |
   |           |                                |           |
   |  Browser  |--------------------------------|  Browser  |
   |           |          Media Path            |           |
   |           |                                |           |
   +-----------+                                +-----------+

Figure 2: Browser RTC Trapezoid

在这张图中, 关键之处是 media path ("low path") 直接在浏览器之间传输, 因此它必须符合 WebRTC 协议套件的规范. Signaling path ("high path") 经由服务器, 服务器可以按需修改, 翻译或操纵信令.

如果两个 Web 服务器由不同实体运营, 则需要通过标准化或其他协商方式就服务器间信令机制达成一致. 现有协议, 例如 SIP [RFC3261] 或 Extensible Messaging and Presence Protocol (XMPP) [RFC6120], 可以用于服务器之间, 而浏览器与 Web 服务器之间可以使用基于标准的协议或专有协议.

例如, 如果两个运营者的服务器都实现 SIP, 则服务器之间可以使用 SIP 通信, 同时应用运行所在的浏览器与 Web 服务器之间可以使用标准化信令机制, 例如 SIP over WebSockets, 或专有信令机制.

类似地, 如果两个运营者的服务器都实现 XMPP, 则 XMPP 可用于 XMPP 服务器之间的通信, 同时应用运行所在的浏览器与 Web 服务器之间可以使用标准化信令机制, 例如 XMPP over WebSockets 或 Bidirectional-streams Over Synchronous HTTP (BOSH) [XEP-0124], 也可以使用专有信令机制.

客户端-服务器信令和服务器间信令所用协议的选择, 以及它们之间转换方式的定义, 均超出本文所描述的 WebRTC 协议套件范围.

浏览器所需的功能组可以或多或少自底向上规定为:

Data transport: : 例如 TCP 和 UDP, 在实体之间安全建立连接的方式, 以及决定何时发送数据的功能: 拥塞管理, 带宽估计等.

Data framing: : RTP, Stream Control Transmission Protocol (SCTP), DTLS, 以及作为容器的其他数据格式, 还包括它们用于数据机密性和完整性的功能.

Data formats: : 在系统之间传递的数据所用的 codec 规范, 格式规范和功能规范. 音频和视频 codecs, 以及数据和文档共享格式, 都属于这一类别. 为了使用数据格式, 需要一种描述它们的方式, 例如会话描述.

Connection management: : 例如建立连接, 就数据格式达成一致, 在一次呼叫期间更改数据格式. SDP, SIP 和 Jingle/XMPP 属于这一类别.

Presentation and control: : 为确保交互以不令人意外的方式运行而需要发生的事情. 这可以包括 floor control, 屏幕布局, 语音激活图像切换以及其他此类功能, 其中系统的某一部分需要各方协作. Centralized Conferencing (XCON) [RFC6501] 和 Cisco/Tandberg 的 Telepresence Interoperability Protocol (TIP) 曾尝试规定此类功能. 许多应用是在没有这些功能的标准化接口的情况下构建的.

Local system support functions: : 不需要统一规定的功能, 因为每个参与者可以按自己的选择实现这些功能, 且不会以其他方必须知晓的方式影响线上比特. 此类别中的示例包括回声消除的某些形式, 本地认证和授权机制, OS 访问控制, 以及本地录制会话的能力.

在每个功能组内, 保持创新自由和全球通信能力都很重要. 以接口而不是实现方式来编写规范有助于创新自由. 任何能够按照接口进行通信的实现都是有效实现. 全球通信能力则依赖于 (1) 核心规范不受 IPR 问题约束, 以及 (2) 格式和协议被充分规定, 足以允许独立实现.

可以把前三个组看作组成 "media transport infrastructure", 把后三个组看作组成 "media service". 在许多场景下, 对 media transport infrastructure 使用共同规范是合理的. 该基础设施可以嵌入浏览器并通过标准接口访问, 而在 "media service" 层则可以 "let a thousand flowers bloom". 但是, 为了实现可互操作的服务, 六个组中至少前五个需要被规定.

最后于 更新