Skip to main content

3. Architecture and Functionality Groups (架构与功能组)

对于基于浏览器的应用，实时支持的模型不假设浏览器将包含电话或视频会议等应用所需的所有功能。愿景是浏览器将具有 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

                       图 1: 浏览器模型

请注意，HTTPS 和 WebSockets 也通过浏览器 API 提供给 JavaScript 应用。

与所有协议和 API 规范一样，协议不限于只能用于与另一个浏览器通信；由于它们已完全规范，任何忠实实现协议的端点都应该能够与在浏览器中运行的应用进行互操作。

图 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            |           |
 |           |                                |           |
 +-----------+                                +-----------+

                   图 2: 浏览器 RTC 梯形图

在此图中，需要注意的关键部分是媒体路径 ("低路径") 直接在浏览器之间传输，因此它必须符合 WebRTC 协议套件的规范；信令路径 ("高路径") 通过服务器，这些服务器可以根据需要修改、转换或操纵信号。

如果两个 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，以及在实体之间安全建立连接的方法，以及决定何时发送数据的功能: 拥塞管理 (Congestion Management)、带宽估计 (Bandwidth Estimation) 等。

Data framing (数据帧): RTP、流控制传输协议 (Stream Control Transmission Protocol, SCTP)、DTLS 以及其他用作容器的数据格式，以及它们用于数据机密性和完整性的功能。

Data formats (数据格式): 编解码器规范 (Codec Specifications)、格式规范 (Format Specifications) 和在系统之间传递的数据的功能规范。音频和视频编解码器，以及用于数据和文档共享的格式，都属于此类别。为了使用数据格式，需要一种描述它们的方法 (例如，会话描述 (Session Description))。

Connection management (连接管理): 例如，建立连接、就数据格式达成一致、在呼叫期间更改数据格式。SDP、SIP 和 Jingle/XMPP 属于此类别。

Presentation and control (呈现与控制): 为了确保交互以不令人惊讶的方式进行而需要发生的事情。这可以包括发言权控制 (Floor Control)、屏幕布局 (Screen Layout)、语音激活图像切换 (Voice-Activated Image Switching) 以及其他此类功能，其中系统的一部分需要各方之间的协作。集中式会议 (Centralized Conferencing, XCON) [RFC6501] 和 Cisco/Tandberg 的 Telepresence Interoperability Protocol (TIP) 是一些尝试规范此类功能的尝试；许多应用是在没有这些功能的标准化接口的情况下构建的。

Local system support functions (本地系统支持功能): 不需要统一规范的功能，因为每个参与者可以根据自己的选择实现这些功能，而不会以其他人必须注意的方式影响线上的比特。此类别中的示例包括回声消除 (Echo Cancellation) (其某些形式)、本地身份验证和授权机制 (Local Authentication and Authorization Mechanisms)、操作系统访问控制 (OS Access Control) 以及进行对话本地录制的能力。

在每个功能组中，重要的是既要保留创新自由，又要保留全球通信能力。创新自由通过以接口而非实现的方式进行规范来帮助；任何能够根据接口进行通信的实现都是有效的实现。全球通信能力通过以下两点来帮助: (1) 核心规范不受知识产权 (IPR) 问题的阻碍，(2) 格式和协议的规范足够完整，以允许独立实现。

可以将前三组视为形成"媒体传输基础设施 (Media Transport Infrastructure)"，将后三组视为形成"媒体服务 (Media Service)"。在许多情况下，对媒体传输基础设施使用通用规范是有意义的，该规范可以嵌入浏览器并使用标准接口访问，并在"媒体服务"层"让百花齐放"；然而，为了实现可互操作的服务，至少需要规范六组中的前五组。

Last updated on