WebRTC现状及实现概要

http://h5dev.uc.cn/article-22-1.html

WebRTC现状及实现概要

2012-12-19 16:03| 发布者: sankyu| 查看: 5062| 评论: 0|原作者:罗智勇

摘要: Google通过把 WebRTC 项目开源，希望浏览器厂商能够将该技术内建在浏览器中，从而使Web应用开发人员能够通过HTML标签和JavaScript API就实现Web音频、视频通信功能。本文讲述浏览器引入 WebRTC技术的必要性、WebRTC ...

1 引言

1.1 编写目的

    本文讲述浏览器引入 WebRTC（Web Real-Time Communication） 技术的必要性、WebRTC现状及实现方法。

    2011 年以前，浏览器之间要实现实时通信需要私有技术，这些技术大部分都是通过插件和客户端来安装使用。对于许多用户来说，插件的下载、安装和更新是一个复杂、繁琐和容易出错的操作。对于开发人员来说，插件的的调试、测试、部署、错误修复和维护同样很难，同时涉及到的一些技术是受版权保护的，整合也是很复杂的。另外，有时很难说服用户来安装插件。

     Google 在 2010 年收购了 GIPS（Global IP Solutions）公司获得 WebRTC 技术，在 2011 年，按 BSD 协议把 WebRTC 开源了，同年 w3c 启动 WebRTC 计划，使 WebRTC成为 HTML5 标准的一部分，目前该规范还在开发中。

    Google 通过把 WebRTC 项目开源，希望浏览器厂商能够将该技术内建在浏览器中，从而使Web应用开发人员能够通过HTML标签和JavaScript API就实现Web音频、视频通信功能。Google 在其官网上列出了使用WebRTC技术的四个理由：

1.  互联网成功的一个关键因素是一些核心技术如HTML、HTTP和TCP/IP是开放和免费实现的。目前，在浏览器通信领域还没有免费、高质量、完整的解决方案。WebRTC就是这样的技术。

2.  该技术的使用已经超过了 8 年，集成了最佳的音频、视频引擎，并被部署到数以百万的终端中，同时这些技术 Google不收取任何费用。

3.  该技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。

4.  通过浏览器，WebRTC把通讯双方的信令状态直接映射到PeerConnection里面来抽象信令处理，这样 开发人员按不同的应用场景选择不同的会话协议，比如 SIP、XMPP/Jingle等等）。

1.2 定义

WebRTC

WebRTC 是 Web Real-Time Communication 的缩写，它是一项在浏览器内部进行实时数据、视频和音频通信的技术，是 Google 2010年以6820万美元收购Global IP Solutions公司而获得一项技术。

MediaStreamTrack

媒体数据源，一个媒体数据源构成一个 MediaStreamTrack，比如音频数据源和视频数据源，多个相互之间有关联的媒体数据源（比如有同步关系的音频视频媒体数据源）构成一个媒体流（MediaStream）。

MediaStream

媒体流，一个媒体流包含 0 个到多个的媒体数据源，媒体流里面的数据源在呈现（render）必须同步。
MediaStream 通过 getUserMedia 获得。

DataChannel

数据通道，两个 WebRTC 终端的连接建立后，它们可以通过这个数据通道传输任意类型的数据。

Peer

通过 WebRTC 进行数据交互的节点或用户或终端，它通常是一个 Web App，它们之间的发现，连接的建立和断开通过 signalling（信令）控制。

PeerConnection

表示一个 WebRTC 通讯连接对象，它维护与这个通讯连接相关的 MediaStream，处理通讯双方信令事件，完成通讯数据的传输。

Signalling

信令，WebRTC 网络通过 Signalling 来发现各个 Peer，通过 Signalling 来控制各个 Peer 之间连接的建立和断开。

STUN

STUN（Session Traversal Utilities for NAT，NAT会话传输应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT 路由器之后的主机之间建立UDP通信。该协议由RFC 5389定义。

ICE

交互式连接建立（Interactive Connectivity Establishment），一种综合性的NAT穿越的技术。
ICE 是由IETF的MMUSIC工作组开发出来的一种framework，可整合各种NAT穿透技术，如STUN、TURN、RSIP（Realm Specific IP，特定域IP）等。该framework可以让SIP的客户端利用各种NAT穿透方式打穿远程的防火墙。

TURN

TURN（Traversal Using Relay NAT），是一种资料传输协议（data-transfer protocol）。通过中继服务器，穿透 NAT 或防火墙使两个 TCP 或 UPD 客户端建立连接。

2 参考资料

·         WebRTC规范 http://www.w3.org/TR/webrtc/ 

·         WebRTC官网 http://datatracker.ietf.org/wg/rtcweb/ 

·         WebRTC wiki http://en.wikipedia.org/wiki/WebRTC 

·         WebRTC实现 http://www.webrtc.org/ 

·         Media Capture and Streams http://dev.w3.org/2011/webrtc/editor/getusermedia.html 

·         Mozilla对WebRTC的介绍 https://developer.mozilla.org/zh-CN/docs/WebRTC 

·         Html5rocks 的 WebRTC 使用例子 http://www.html5rocks.com/en/tutorials/webrtc/basics/

3 现状

3.1 规范现状

    规范现已经发布 1.0 版，处在草案状态，现只支持 1 对 1 通讯，不支持 1 对多通讯，也不支持多对多通讯。

    按官网的路线图，预计 2013 年第一季度发布正式推荐标准。

3.2 Google WebRTC（http://www.webrtc.org/）库现状

    WebRTC 已经实现了大部分功能，小部分功能还不是很完善，比如：

·         MediaStream 里的音频无法给 audio 标签处理，也无法给其它 Web API（比如 Web Audio）处理；

·         ICE 尚未完全兼容规范 RFC 5245，将要发布的 Chrome M23 会有第一个实现；

·         DataChannel 尚未实现，这个主要是因为标准委员会还在讨论该规范。

3.3 浏览器实现现状

    Windows 环境下，据说 IE 从版本 10 开始支持，Chrome 从版本 20 开始支持，Firefox 从版本 17（预计在 2013 年 1 月发布）开始支持，Opera 从版本 12 开始支持，爱立信在 2011-05-26（http://labs.ericsson.com/blog/beyond-html5-experiment-with-real-time-communication-in-a-browser）发布了一个针对 Ubuntu 修改版的 webkit 可以测试 WebRTC 功能。

    手机/平板方面，目前只有爱立信在 2012.10.19 发布的移动浏览器 Bowser 支持（https://labs.ericsson.com/blog/bowser-the-world-s-first-webrtc-enabled-mobile-browser）。Bowser 采用自己实现的 WebRTC 框架（没有使用 webrtc.org 的框架），媒体引擎采用 GStreamer，在 iTunes App Store 和 Google Play 有下载，运行效果如下图：

4 设计

4.1 系统框架

    如上图，浏览器里的 WebRTC 有两个明显不同的层次：

1.  浏览器开发人员关注的 WebRTC C++ API 层

2.  Web App 开发人员关注的 Web API 层

    图中，各个功能模块介绍如下：

4.1.1 Your Web App

    Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

4.1.2 Web API

    面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用，对应规范参考：http://www.w3.org/TR/webrtc/。

4.1.3 WebRTC C++ API

    本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API。

4.1.4 Transport / Session

    传输/会话层，组件来自 libjingle（但不使用或不要求使用 xmpp/jingle 协议）。

    1.RTP/SRTP Stack

    实时传输协议(SRTP 带加密)，浏览器之间建立连接后，通过 RTP 协议传输音视频数据。

    2.STUN/ICE

    STUN/ICE 组件允许不同网络环境下的浏览器建立直接或间接的通讯连接。

    3.Session Management

    是一个抽象会话层，执行会话建立和管理功能，这层协议留给应用开发者实现。

4.1.5 VoiceEngine

    音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。功能包括音频 iSAC 编码，iLBC 编码，音频抖动缓冲处理，回声消除，噪音抑制等等。

4.1.6 VideoEngine

    视频引擎是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。功能包括视频 VP8 编解码，视频抖动缓冲处理和图像质量增强等等。

4.2 概要设计

    WebRTC 由三个部分组成：

    1.MediaStream

    来自本地的音频视频流，或者来自远端浏览器的音频视频流。

    2.PeerConnection

    执行音频视频调用，支持加密和带宽控制。

    3.DataChannel

    采用点对点传输，用来传输常规数据。

    各部分的关系如下图：

4.2.1 MediaStream 实现

媒体流，一个媒体流包含 0 个到多个的媒体数据源，媒体流里面的数据在呈现（render）的时候必须同步进行（就是常说的音视频同步）。WebRTC 客户端连接建立后传递的数据流就是这个东西。 MediaStream 通过 getUserMedia 获得，MediaStream 的实现由 w3c 规范 Media Capture and Streams（http://dev.w3.org/2011/webrtc/editor/getusermedia.html）定义。

4.2.2 Signalling 实现

    Signalling 也叫信令，它不是 WebRTC 的一部分，但对于 WebRTC 应用来说很重要！

     除了使用 PeerConnection 在客户端（Peer）之间传输数据流（MediaStream），还需要一种机制在客户端之间传递控制信息，通过控制信息处理客户端之间的发现、连接建立、连接维护和连接关闭等任务，这种机制就是通信领域常说的信令（Signalling）。

    信令实现的方法和协议 WebRTC 没有指定，这样 WebRTC 应用的开发者就可以采用合适他们的协议，比如 SIP、XMPP 等等，采用其它合适的双向通讯通道，比如 WebSocket、XMLHttpResuest（XHR）、Google Channel API，来完成信令任务。http://apprtc.appspot.com/ 的测试例子就是通过 Google Channel API 来实现的。

    启动一个 WebRTC 会话，WebRTC 需要以下几个信息：

·         本地客户端的配置信息；

·         远程客户端的配置信息；

·         远程参与建立P2P连接的信息：主要是 IP 和端口。

    客户端配置信息叫做 SessionDescription，结构必须符合 Session Description Protocol（SDP，http://tools.ietf.org/html/rfc4566）的要求。

    信令的处理过程大致如下：

1.  呼叫方发送 offer；

2.  被呼叫方接受这个 offer；

3.  被呼叫方方式 answer；

4.  呼叫方接受 answer。

    上述信令处理过程叫做 JSEP（JavaScript Session Establishment Protocol，规范为http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/）。JSEP 在最新版本的 chromium 里有实现参考。

4.2.3 PeerConnection 实现

    WebRTC 连接对象，负责客户端信令处理，连接建立，媒体传输等任务。

    PeerConnection 参与了 WebRTC 应用开发三个主要模块：发起连接，接受连接和中止连接。

    1. 客户端发起一个连接的调用图如下：

    2. 客户端接受一个连接的调用图如下：

    3. 客户端中止一个连接的调用图如下：

4.2.4 DataChannel 实现

    数据通道，现有规范尚未完善，该功能开源库 webrtc.org 还在开发中，待 webrtc.org 库实现后再考虑整合和移植。

5 实现

    Chrome 从版本 20 开始支持 WebRTC，实现主要参考 chromium 里的实现进行移植，主要包括以下几个方面：

·         WebKit 库方面，除了适配，已经支持 WebRTC，操作如下：

·         编译时启用宏 ENABLE_MEDIA_STREAM；

·         采用 http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/Modules/mediastream 下面的所以 idl 文件，并把生成的 cpp 文件添加到 WebCore工程里；

·         把 http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/Modules/mediastream 下面的所有 cpp 文件添加到 WebCore工程里；

·         把 http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/platform/mediastream 下面的所有 cpp 文件添加到 WebCore工程里；

·         适配开发

适配的实现主要是要实现 PeerConnection，参考实现是：

http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/platform/mediastream/chromium

（chromium 的适配使用了 http://www.webrtc.org/ 库）

·         WebKit已有实现关键类介绍

·         各种事件：

·         MediaStream 的定义及协作图如下：

·         MediaStream 适配接口

其中 MeiaStreamCenterBlackBerry 是 BlackBerry 上的实现，MediaStreamCenterChromium 是 Chromium 的实现，MediaStreamCenterGStreamer 是采用 GStream 框架的实现。

·         PeerConnection

·         DataChanne（数据通道）

·         RTCIceServer（RTC Ice 服务器）

·         RTCIceCandidate（RTC 参与者）

·         RTCSessionDescription（RTC 会话描述对象）

6 部署

    WebRTC Web APP 应用，不像其它 Web APP 应用，网页提供代码，浏览器支持就可以了。一个典型的 WebRTC Web APP 应用的部署包括以下 3 个部分：

·         Web APP 开发

参考例子为：http://webrtc-samples.googlecode.com/svn/trunk/apprtc/index.html

·         信令（Signalling）服务器开发及部署

参考例子为：http://webrtc-samples.googlecode.com/svn/trunk/apprtc/apprtc.py

·         STUN 或 TURN 服务器开发及部署

STUN 参考：http://en.wikipedia.org/wiki/STUN

TURN 参考：http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT

7 测试

·         采用http://apprtc.appspot.com/ 测试。源码在：http://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/。

·         按教程 http://www.html5rocks.com/en/tutorials/webrtc/basics/ 指导开发 Web APP 进行测试。

·         采用目录 http://svn.webkit.org/repository/webkit/trunk/LayoutTests/fast/mediastream 下的页面进行测试

 

本文为UC原创文章，未经许可或授权不得转载。如需转载请联系[e-mail]