WebRTC现状及实现概要
WebRTC现状及实现概要
摘要: 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.2 定义
2 参考资料
3 现状3.1 规范现状
规范现已经发布 1.0 版，处在草案状态，现只支持 1 对 1 通讯，不支持 1 对多通讯，也不支持多对多通讯。
按官网的路线图，预计 2013 年第一季度发布正式推荐标准。
3.2 Google WebRTC（http://www.webrtc.org/）库现状
WebRTC 已经实现了大部分功能，小部分功能还不是很完善，比如：
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 有两个明显不同的层次：
图中，各个功能模块介绍如下：
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 需要以下几个信息：
客户端配置信息叫做 SessionDescription，结构必须符合 Session Description Protocol（SDP， http://tools.ietf.org/html/rfc4566）的要求。
信令的处理过程大致如下：
上述信令处理过程叫做 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 里的实现进行移植，主要包括以下几个方面：
6 部署
WebRTC Web APP 应用，不像其它 Web APP 应用，网页提供代码，浏览器支持就可以了。一个典型的 WebRTC Web APP 应用的部署包括以下 3 个部分：
7 测试
|