RTCWeb及其与IMS的融合研究

2013-10-08乐利锋段晓东

电信科学 2013年1期

乐利锋，彭晋，段晓东

（中国移动通信研究院北京 100053）

1 引言

Web应用已成为互联网应用最成功的模式之一，其应用范畴已经渗透人类社会生活的各个领域。人们只要通过一款浏览器，就可以享受到无穷无尽的Web服务，如各种电子商务、网络游戏、社区服务及各种网络交友等。与此同时，Web技术所带来的优势（如统一的客户端和较好的可维护性），使一些传统应用纷纷转型到Web模式。Web应用开发的简单快速也受到开发者青睐，开发者只需要一次开发就可以在任何地方部署，代码片段很容易在开发者之间被复制和粘贴，越来越容易掌握的JavaScript库使开发更加快捷。

Web浏览器一直随着Web应用的需要持续加入新的Web 特性，W3C（world wide web consortium，万维网联盟）标准化组织追求的Open Web Platform[1]是所有Web技术的集合，不仅包括基础 Web技术，如 HTML（hypertext markup language，超文本标记语言）、CSS（cascading style sheet，级联样式表）和 JavaScript及 HTTP（hypertext transfer protocol，超文本传输协议）等；还包括新的Web技术，如HTML5[2]，允许开发者免费使用它所发布的技术。可以预见，未来Web将逐渐成为一种准入门槛较低、推广成本可控的统一应用平台。

基于Web的实时通信应用可以吸引越来越多的用户。Facebook[3]推出了整合Skype的视频聊天服务，首次使用该功能的用户需要安装插件；GoogleTalk[4]网页版的正常使用需要安装Google话音和视频聊天插件，在浏览器中成功安装插件后，可以直接在Gmail[5]或iGoogle[6]中进行视频和话音通话。但这些插件对于不同浏览器需要不同的开发实现，且需要用户安装，具有一定的安全隐患。为了避免引入新插件，一些 Web 网络电话（如 Alicall[7]、FlashVoIP[8]）采用普及程度比较高的flash player插件实现实时通信功能，可重用flash插件自有RTMP（real time messaging protocol，实时消息传送协议）[9]信令和媒体传输协议。但flash插件方式需要依托第三软件提供商的支持，大规模商用更需要支付相当可观的费用。

如果彻底不引入插件，Web实时通信客户端在执行效率方面想接近传统客户端或插件客户端的效果，需要浏览器提供更多新特性的支持。为了实现实时通信功能，浏览器至少需要具备会话管理、音视频编解码引擎和媒体传输等功能。会话管理功能允许开发者为上层应用实现呼叫建立和管理；音视频编解码引擎功能允许外设（如麦克风及摄像头）将采集的数据进行编码并发送给网络，或者将接收的媒体进行解码供外设（如音箱或者显示器）呈现；媒体传输功能实现对不同网络的NAT（network address translation，网络地址转换）或防火墙穿越，并实现对媒体内容的封装传输。

对于无插件Web实时通信应用开发，开发者需要调用浏览器API（application programming interface,应用程序编程接口）才能使用其实时通信模块功能。如果缺少对实时通信模块API的统一使用规范，不同浏览器厂商对API的定义和使用可能出现很大的差异，开发者需要了解不同版本的API使用方法，从而可能会影响开发周期。所以，业界希望Web浏览器的实时通信能力被标准化的呼声越来越高。IETF（internet engineering task force，工程任务组）和W3C这两大标准化组织从2011年开始积极推进基于Web浏览器的实时通信（real-time communication in web-browsers，RTCWeb）标准化工作[10,11]，力图提出一个能够在Web浏览器上实现用户之间话音和视频等实时通信的标准化框架。IETF的主要工作在于标准化基于浏览器的实时通信的架构和协议；W3C的主要工作在于标准化浏览器与Web应用之间的API，即上层Web应用通过JavaScrip编程调用这些被标准化的API，实现对浏览器RTCWeb功能的使用，如捕获本地设备的媒体内容、呈现媒体内容、建立点对点媒体通信等。随着RTCWeb标准化的逐渐深入和影响力的逐步增强，各大浏览器厂商如 Chrome、Mozilla Firefox、Safari和Opera纷纷宣布支持或部分支持RTCWeb功能，RTCWeb浏览器逐渐步入舞台并占据相当的市场份额。

2 RTCWeb关键技术

2.1 RTCWeb通信模型

IETF RTCWeb工作组建议的典型架构[12]如图1所示。Web客户端是基于浏览器的融合JavaScript、HTML及CSS的技术客户端实现，对浏览器和Web服务器的会话信令面操作是通过JSEP控制实现的；通过JavaScript调用RTCWeb API，实现对浏览器能力的使用；Web客户端通过JavaScript与Web服务器传递基于Web Socket承载的RTCWeb信令消息。RTCWeb信令协议由Web应用定义，可以是标准的协议，如 SIP（session initiation protocol，会话初始协议）、XMPP （extensible messaging and presence protocol，可扩展消息处理现场协议）或私有协议，但媒体协商可参考基于Offer/Answer模型的ROAP（RTCWeb offer/answer protocol）；Web服务器之间采用双方认同的协议，如 SIP或者 XMPP；浏览器之间采用RTP（real-time transport protocol，实时传输协议）或 SRTP（secure RTP，安全实时传输协议）用于媒体传输，同时采用ICE（interactive connectivity establishment，交互式连接建立）协议用于防火墙穿越。

图1 RTCWeb通信模型

2.2 RTCWeb浏览器API

W3C WebRTC工作组的关注重点在于浏览器端API的标准化[13]，通过调用标准化API实现从本地设备（如摄像头、麦克风或网络摄像机）捕获并呈现本地音视频媒体内容、通过NAT穿越技术建立点对点连接、基于点对点连接交换媒体内容。这些功能的实现主要由Stream API和Peer Connection两大类API实现。

Stream抽象了对实际媒体流表示及操作的方法和属性，目前定义了若干重要的接口，主要是Media Stream。Media Stream对象可以表示从远端节点或者发送给远端节点的媒体流；从网络传输Media Stream角度看，每个Media Stream对象都有一个输入和输出，来自远端节点的Media Stream（由Peer Connection实例化产生）可以看作输入；本地设备产生的Media Stream（调用getUserMedia函数产生）传给远端节点便有一个输出；对于媒体流的呈现，需要专用URL来表示一个媒体流并在网页中表现出来（调用createObjectURL函数生成）。

Peer Connection抽象了浏览器之间信令交互及媒体通道建立的方法和属性，通过开通媒体通道，Media Stream对象表示的媒体流可被送到对端。一个Peer Connection对象实现3类功能，即ICE代理（利用ICE方式实现NAT穿越，如依赖STUN或者TURN服务器）、Peer Connection状态（标识当前连接状态，如“new”、“opening”、“active”等）和ICE 状态（标识穿越状态，如“new”“waiting”“connected”等）。此外，Peer Connection提供创建媒体协商的方法和属性，如Offer/Answer消息构建方法（createOffer/createAnswer）及SDP属性设置（setLocal Description/setRemote Description）等。