移动互联网WebRTC及相关技术

董振江 李从兵 王蔚 吕达

针对Web实时通信（WebRTC）技术，提出一种WebRTC实时通信服务的改进设计方案。方案在客户端侧、服务端侧、客户端与服务端之间的通信等部分对WebRTC进行了改进。改进方案采用了HTML5 WebSocket技术、媒体协商与合成技术、网络地址转换（NAT）/防火墙穿越技术、基于会话发起协议（SIP）栈的信令交互技术、P2P通信安全技术，较好地解决了跨浏览器运行、对客户端侧处理能力的过分依赖和带宽消耗等问题，提高了系统的可扩展性。

WebRTC技术；应用模式；跨浏览器运行；可扩展性

This paper describes an improved design for WebRTC technology. With this design， WebRTC communication at client side， server side， and between these two sides is improved. HTML5 WebSocket， media negotiation and synthesis， network address translator（NAT）/firewall traversal， Session Initiation Protocol （SIP） signaling interaction， and P2P communication security are used in this improved design. These solve problems such as cross-browse running， over-reliance on the client-side processing， and bandwidth problems. With this design， they can be made more scalable.

WebRTC technology； application model； running across browsers； extension

Web实时通信（WebRTC）[1]是一种构建在Web浏览器基础上的实时音视频通信的技术。目标是在不安装任何插件的前提下，开发者基于浏览器利用简单的Web技术方便快捷地开发出丰富的实时Web多媒体应用。

随着网络带宽和浏览器版本的升级，WebRTC将会对传统的实时通信业务造成巨大影响，正逐渐成为主流的实时通信方式。Google已开始在Android平台的新版Chrome浏览器上提供WebRTC支持，预计2013年至少有10亿终端支持WebRTC。中国著名的融合通信论坛CTI调查结果显示[2]：87%电信企业考虑将WebRTC融入产品战略，86.9%的受访者表示WebRTC对于他们的整体产品战略而言具有十分重要的意义，49%的受访者打算在未来1年内部署WebRTC解决方案。

WebRTC由Google收购的Global IP Solution公司开发，并由Google在2010年向外开放，目前已成为实时通信的技术热点，在W3C和IETF都成立了WebRTC相关的标准组，并得到业界越来越多厂商的支持。

与传统的通信技术相比，WebRTC具备了如下明显优势：

（1）用户使用方便，不需要安装插件或者不同的客户端。

（2）用户体验一致性高，升级方便快捷，在服务器侧完成。

（3）基于JavaScript或超文本链接标记语言（HTML）开发简单快捷。

（4）跨操作系统。开发者不需要为专门的操作系统开发不同的版本，一次开发统一版本。

（5）开发者重点关注业务本身，不用太关注媒体处理。

1 WebRTC标准进展

负责WebRTC的标准组织是W3C和IETF。

W3C WebRTC负责定义客户端侧Javascript API，这些应用编程接口（API）用于帮助Web应用完成Web浏览器之间点对点或点对多点之间的实时通信。

W3C WebRTC标准组的主要成员由Web浏览器厂商组成，包括Google、Microsoft、Mozilla和Opera等。

IETF RTC-Web负责定义浏览器之间的实时通信协议和格式。该标准所关注的是媒体编解码、网络传输、网络地址转换（NAT）/防火墙穿越以及安全与隐私等内容。其主要成员包括Microsoft、Google、Skype、yahoo、Cisco和FT（Orange）等。

目前，WebRTC标准已经提供了Network Stream、RTCPeerConnection以及DataChannel共3类API，分别用来完成媒体流的获取、点到点的媒体、NAT/防火墙穿越连接的协商、浏览器之间音视频流之外的数据传输。3类API中，Network Stream API和RTCPeerConnection API比较成熟，DataChannel API则是新增加的特性，目前的应用还不太广泛。

随着WebRTC标准的不断推进和完善，WebRTC标准得到越来越多浏览器厂商的支持。表1给出了目前各种浏览器对于WebRTC技术的支持情况。

在WebRTC技术的运用上，浏览器厂商Google、Mozilla，VoIP中间件平台Mobicents[3]（目前已被Redhat收购）、通信厂商Livecome[4]以及一些Web即时通信服务开发人员都进行了相应的探索，并提供了相应的原型实现。

2 WebRTC运用模式

WebRTC应用主要有3种模式：

（1）WebRTC接入传统的音、视频业务

电信运营商与解决方案提供商将WebRTC作为传统音视频业务中的一个新的接入方式，如传统呼叫中心增加浏览器方式的接听、传统会控系统增加浏览器终端等。

该模式重点解决WebRTC技术与传统应用架构之间的差异和兼容问题：在WebRTC与传统的应用架构之间，加入一个负责协调两者差异的网关设备。

中兴通讯WebRTC-IMS网关的接入方案，由WebRTC-IMS网关负责WebRTC与传统IMS网络之间的信令转换、媒体流中继以及NAT/防火墙穿越机制的转换等工作。该方案具有下面的优势：

·增加传统音视频业务的软接入方式，同时不需要为增加浏览器的接入做各种各样的插件，大大减少了传统浏览器客户端的工作量。

·利用传统业务架构中的媒体服务器来强化即时通信中音视频的处理能力，提升WebRTC接入的用户体验。

·可有效减少WebRTC接入对客户端侧处理能力的依赖和带宽消耗。

（2）轻量级Web实时通信服务

利用WebRTC标准接口，开发轻量级Web视频通话、Web音视频会议中心是WebRTC的典型应用场景。业界比较有代表性的原型包括Mobicents SIP Servlet[5]、Conversat.io[6]（现更名为Talky.io）、Chatdemo[7]等。

这种场景中，各原型在应用架构上基本上都采用了“去中心化”的设计思路：将多方之间的媒体协商过程分解成多个端到端的协商过程，传统上由媒体服务器来完成的功能都转移到了客户端浏览器侧。

当两个浏览器实时通信时，通过信令交互获取到双方都支持的媒体格式和传输协议后，直接按照约定好的原则进行端到端的媒体传输。一旦有第三方加入进来，则由第三方代理分别在信令层面发起对前两个用户代理的协商，之后的过程与两方之间通信过程一致。

该方案的优势是开发简单快捷，基本不关注媒体处理。缺点是随着浏览器端的增加，每个浏览器需要向其他浏览器端分别发送媒体流，同时接受来自其他浏览器端的媒体流，这对浏览器端的媒体处理能力提出了较高的要求，相对应的带宽需求也比较大。

（3）综合型的Web实时通信服务

在终端采用WebRTC，在服务侧结合电信的多点控制单元（MCU）等设备，解决掉混频和混音问题，增强对各种应用场景的支持，同时减轻对网络的压力。

综合型的Web实时通信服务通过采用轻量级Web实时通信服务当中的点对点以及点对多点的媒体协商策略，让客户端之间就可以完成媒体协商过程，进而使得整体应用架构变得简洁。同时，它还在服务侧引入了多点控制单元来接管多方媒体流的处理，较大程度地缓解了客户端侧处理压力，给WebRTC在各种场景中的充分应用创造了有利条件。

综合型的Web实时通信服务融合了前两种方案各自的优势，能够适应大规模应用。

3 WebRTC技术方案分析

与改进

3.1 当前WebRTC应用存在的技术

问题

作为一种发展中的技术和标准，WebRTC还有诸多不够完善之处，这些缺陷给WebRTC的利用带来了不少挑战：

·与传统的会议视频业务相比，媒体控制弱，需要增强以适应复杂会议控制的需求。

·媒体流的P2P直传对给客户端的处理能力带来挑战。2到4个参与方比较合适，超过4个参与方对客户端处理能力都提出了很高的要求。业界应用PC端参与方很少超过6个参与方。如果是移动客户端则问题更大。

·端到端直传大量媒体流的上传下载带来巨大的带宽消耗。不仅增加了用户使用服务的成本，对用户体验造成不良的冲击。

·当前浏览器厂商在WebRTC标准Javascript API和HTML5 API的设计上，存在命名或方法调用的差异[8-9]，在一个浏览器正常运行的WebRTC应用，在另一套浏览器环境可能会出现异常。

·通过WebRTC Javascript API直接操作本地音视频媒体文件和相关设备能力也为系统的安全性带来挑战[10]。

3.2 设计方案的改进

为了有效解决跨浏览器运行、减少应用运行对客户端侧处理能力的依赖和带宽消耗，同时提高系统的可扩展性，本文提出了一种利用WebRTC技术开发轻量级Web实时通信服务的改进思路，其整体框架如图1所示。

图1主要包括客户端侧、服务端侧、客户端与服务端之间的通信，说明如下：

（1）客户端侧

在客户端侧，Browser负责提供WebRTC标准接口支持，SIP Stack负责提供客户端侧会话发起协议（SIP）[11]信令的处理。WebRTC封装库建立在Browser WebRTC Javascript API和SIP Stack的基础上，解决客户端与服务端双向通信、媒体及防火墙穿越连接协商以及跨浏览器运行等方面的问题。Webrtc APP负责完成用户界面展示。

（2）服务端侧

服务端侧包括交互式连接建立（ICE）[12]服务器、MCU、Web服务器以及信令服务器4个网元。其中，ICE服务器用于与客户端侧浏览器交互，帮助客户端获取到能够穿越NAT/防火墙的ICE地址。MCU负责对各方代理传输过来的视频流进行合成，并将最终合成的多方视频流发送给各方代理。Web服务器用于运行Webrtc APP。信令服务器用于对客户端的SIP请求进行处理和路由分发，并辅助完成用户认证、用户管理、会议控制与录制、会议计费等功能。在实际的部署中，上述4种网元既可以单独部署，也可以根据需要部署在同一台或几台服务器当中。

（3）客户端与服务端之间的通信

NAT/防火墙穿越的客户端程序与交互式连接建立服务器通信遵从数据报协议通过网络地址转换简单穿越（STUN）[13]、中继NAT实现的穿透（TURN）[14]等标准协议，采用数据报协议（UDP）进行消息传输。客户端与服务端双向的SIP交互采用SIP over WebSocket[15]技术。

客户端与服务端之间媒体流传输采用实时传送协议/实时传输控制协议（RTP/RTCP）格式。Web服务的访问采用超文本传输协议（HTTP）。

基于上述框架，一个大致的多方视频通信过程可以简要描述如下：

·用户通过客户端浏览器访问Web服务器提供的服务。

·客户端之间通过信令服务器注册并借助ICE服务器完成多方之间点多多点的媒体协商过程。

·MCU接收各方按照约定的格式传送的本地音视频流，并将其按照相关策略进行混音、混频等后台处理，然后将得到的合成流再返回给参会的各方。

·各方浏览器完成媒体流的接收和显示。

·建立起多方通信过程。

3.3 采用的关键技术

（1）HTML5 WebSocket技术

传统实时通信中，通常采用轮询或长轮询的方式来实现。这种通过增加客户端请求频次或延长服务端响应时段的做法，虽然在一定程度改善实时性服务程序的体验，但其基于HTTP的请求响应模式，无法做到真正的实时。此外，还会给客户端的带宽和服务端的资源消耗带来额外的负担。

为了减少实时通信的延迟，降低带宽消耗，HTML5工作组制订了WebSocket通信标准。通俗地说，HTML5 WebSocket是通过在Web上的单个Socket定义了一个全双工通信信道，进而为Web实时通信带来显著的改善。

在客户端与服务端通信之前，首先需要完成一次WebSocket握手过程来建立双方之间的连接。一旦连接建立起来，客户端与服务端之间就可以双向进行数据的发送或接收。这样，当服务端有数据更新时，就可以直接推送到客户端侧，而不需要等待客户端侧是请求。

在音视频通信这类实时性非常强的应用场景中，采用HTML5 WebSocket技术可以极大地提高服务的实时性，并通过降低传输载荷减少带宽消耗。

（2）媒体协商与合成技术

上述改进思路中，各方媒体信息的协商还是放在客户端自己来完成。对于多方参会情形而言，在实现上还是需要将多方的协商过程分解成多个端到端的协商过程，可选的协商策略包括图2、图3所示的两种实现方法。

理论上来说，在多方之间的媒体协商完毕之后，就可以实现多方之间的媒体流的直传通信了。但这种应用方式会带来显著的问题，以4方会议为例，每一方需要同时向外发送3路本地视频流，同时接收其他3方的视频流。这样，客户端侧能够支撑的用户量非常有限，而且网络带宽消耗巨大。

为了解决该问题，需要在服务端借助MCU完成媒体流的转换、合成等工作。引进MCU之后，每个客户端只需要向外发送本地的一路视频流，同时也只需要接收从MCU合成后的一路视频流。无疑，这将给系统的性能带来极大的改善。

（3）NAT/防火墙穿越技术

在跨局域网环境中使用Web音视频通信时，必须要有一套穿越NAT/防火墙的设备来辅助完成媒体流的路由传输。

在IETF-RTC Web标准中，规定了客户端浏览器当中WebRTC需要支持ICE框架，这样服务端就需要提供相应的ICE服务器。

在穿越方案的选择上，同时支持STUN和TURN两种服务器。其中，STUN服务器用于完成非对称NAT穿越，TURN则负责完成对非对称NAT穿越及防火墙的穿越。通过两者的协同，保障WebRTC媒体流的畅通。

（4）基于SIP栈的信令交互技术

在W3C WebRTC标准中，并没有对客户端与服务端之间的信令进行标准化。

SIP以其简单、灵活和可扩展等特性，受到业界越来越多的关注和支持，并已成为下一代通信事实上的标准。

为完成客户端与服务端SIP信令交互，需要在客户端侧使用Mobicents JAIN-SIP标准的参考实现来提供SIP栈服务，服务端侧利用SIP Servlet来处理客户端侧请求或进行路由分发。一个服务端充当代理实现路由分发的大致交互过程如图4所示。

（5）P2P通信安全技术

为了防止浏览器程序对本地资源的滥用，在WebRTC即时通信服务框架中，我们参照文献[10]引入了沙箱技术。该技术的核心思路是，将外部站点划分成可信站点和不可信站点。其中，可信站点认为是安全的，能够访问一切的本地资源（或者受限的部分资源）；不可信站点由于存在安全隐患，将其放入沙箱之中，不能直接访问本地资源。

对于可信与非可信站点的甄别，采用IETF中的同源策略（SOP）[16]加以考虑：即一个网页的安全性由其来源决定，需要对其所使用的协议、主机和端口进行同源匹配；为每一个起源都分配一个与之匹配的安全访问策略，比如从一个站点（记为A）访问另一个目的站点（记为B）的资源时，不允许访问B站点的本地加密文件等等。

此外，为了防止恶意站点通过Javascript API进行分布式拒绝服务攻击（DDOS）[17]攻击或通过浏览器协议包仿真域名服务器（DNS）攻击公司的DNS，因此还引入像定期扫描、检查访问者来源等辅助防御措施。

4 结束语

当前WebRTC技术和标准尚不成熟，在实用中还存在不少问题，如很多功能尚未定义、不同浏览器间的不兼容、客户端侧处理能力要求较高以及高带宽消耗等问题。本文提出一种WebRTC实时通信服务的改进设计思路，较好地解决了当前WebRTC技术应用面临的主要问题，对于WebRTC技术的产品化具有重要的借鉴价值和现实意义。

随着LTE、Wi-Fi和有线宽带的普及、带宽得到解决，PC和各种移动终端处理能力大幅提升，各种终端上浏览器基本都会支持WebRTC，基于WebRTC的实时音视频通信会成为一种普遍服务。综合型的Web通信服务方案将会成为一种较为理想的应用模式。

HTML5和WebRTC技术和标准正走向成熟、快速普及，传统的IM、桌面共享、电子白板、音视频会议录制等将进一步朝Web化的方向发展，并将最终融合到一个完整的基于Web的统一通信系统当中。届时，用户基于浏览器就可以进行全方位的沟通与交流，人际交互将变得更加简便、快捷。

参考文献

[1] WebRTC 1.0： Real-time Communication Between Browsers [EB/OL]. [2013-08-21]. http：//www.w3.org/TR/Webrtc/#rtcpeerconnection.

[2] CTI论坛调查 [EB/OL]. [2013-09-11]. http：//www.ctiforum.com/news/baogao/370610.html.

[3] Mobicents Project. [EB/OL]. [2013-07-15]. http：//hudson.jboss.org/hudson/view/All/job/Mobicents/.

[4] livecome Webrtc demo [EB/OL]. [2013-03-11]. http：//lwork.hk：8086.

[5] Mobicents SIP Servlet. [EB/OL]. [2013-07-22]. http：//dev.telestax.com/sipservlets/wiki/HTML5WebRTCVideoApplication

[6] talky.io [EB/OL]. [2013-07-15]. http：//talky.io.

[7] chatdemo [EB/OL]. [2013-08-18]. http：//ishare.iask.sina.com.cn/f/35083616.html.

[8] simpleWebrtc [EB/OL]. [2013-08-17]. https：//github.com/HenrikJoreteg/SimpleWebRTC.

[9] Webrtc.io [EB/OL]. [2013-09-11]. https：//github.com/WebRTC/Webrtc.io-client/blob/master/lib/ Webrtc.io.js.

[10] 李琳. 基于Web浏览器的P2P实时通信的安全性分析 [J]. 计算机安全， 2012，06：54-56.

[11] Session Initiation Protocol [EB/OL]. [2013-04-19]. http：//www.rfc-editor.org/rfc/rfc3261.txt.

[12] RFC5245-Interactive Connectivity Establishment [EB/OL]. [2012-11-17]. http：//www.packetizer.com /rfc/rfc5245/.

[13] RFC3489-Simple Traversal of User Datagram Protocol [EB/OL]. [2013-06-16]. http：// www.ietf.org/rfc/rfc3489.txt.

[14] RFC5766-Traversal Using Relays around NAT （TURN）： Relay Extensions to Session Traversal Utilities for NAT （STUN） [EB/OL]. [2013-08-22]. http：//www.rfc-editor.org/info/rfc5766.

[15] draft-ietf-sipcore-sip-Websocket-04 [EB/OL]. [2013-08-22]. http：//tools.ietf.org/html/draft-ietf-sipcore -sip-Websocket-04.

[16] IETF-Security Considerations for RTC-Web draft-ietf-rtcWeb-security-02 [EB/OL]. [2012-03-12]. https：//datatracker.ietf.org/doc/draft-ietfrtcWeb-security.

[17] 吴敏， 王汝传， 王治平. 基于支持向量机的P2P网络DoS攻击检测 [J]. 计算机技术与发展， 2009，11：151-154.