付 斌，杨 鑫，王 松，林 鸿

（1.中国电信股份有限公司北京研究院 北京 100035；2.法国电信北京研发中心 北京 100190）

1 引言

WebRTC（Web real-time communication）是近年来兴起的一项 OTT（over the top）VoIP（voice over IP）技术，目标是通过简单的JavaScript调用即可在浏览器上实现点对点语音、视频和文件共享等业务。因为其开放、开源且具有极大的使用便利性，从推出以来就受到了业界特别是互联网和通信行业的广泛关注。在互联网应用爆发式增长的大环境下，这种实时通信功能已经成为各种互联网应用的基础要素，也是WebRTC受到如此关注的主要原因。对于电信业而言，WebRTC提供的语音、视频通信服务一定程度上会与传统的电信业务产生竞争关系，对于同样基于VoIP技术的IMS（IP multimedia subsystem）会产生一定的替代。另一方面，人们也在探索把WebRTC技术应用于IMS中，如以Web方式接入IMS服务，甚至整体上作为运营商VoIP业务的一种选项。

WebRTC包括语音引擎（voice engine）、视频引擎（video engine）、传送（transport）功能和会话管理（session management）功能以及对本地音频、视频、网络的操作功能和向浏览器提供的 API（application programming interface）。目前公开的核心技术包括音视频编解码技术，如音频的NetEQ算法、回声抑制、噪声消除，视频的抖动处理、图像增强等。绝大部分技术来源于Google向业界开源的一些项目（参阅http://www.webrtc.org）。媒体的传送部分重用ICE（interactive session establishment）技术，支持对4种类型NAT（network address translation）或防火墙的穿透，实现点对点、点对多点等多种方式媒体通路的建立和传送。

在Google等公司的推动下，WebRTC的标准化工作取得了快速发展。2011年5月，IETF成立RTCWeb工作组负责需求、总体方案和协议的制定，并为W3C（World Wide Web Consortium）提供输入。与此同时，W3C成立WebRTC工作组负责客户端API的定义，几个主要的浏览器（Firefox、Chrome、Opera）也都紧跟着标准化进展的步伐推出了支持WebRTC的版本。另外，3GPP也启动了WebRTC access to IMS的工作项目，并在2013年7月得到了全球主要运营商和设备商的一致支持和积极参与。研究的内容主要是实现WebRTC客户端与IMS客户端的互操作性，因此需要对IMS进行增强。

2 WebRTC发展趋势及其对通信业务的影响

2.1 WebRTC技术发展趋势

近年来电信市场通信业务增长缓慢，来自电信市场研究公司TeleGeography的一份报告显示，2012年国际电话通信量仅增长5%，达到4 900亿分钟。而与此同时，互联网通信类应用却保持着爆发式的增长速度。以Skype为例，2012年语音和视频流量增长44%，达到1 670亿分钟，相当于全部电信运营商国际电话通信总量的1/3，这还不包括其他流行的通信类应用（如 GTalk、微信、Viber、Line、Nimbuzz、KakaoTalk 等），对比如图1所示。

图1 国际电话通话分钟数与Skype的对比(来源：TeleGeography)

WebRTC技术的出现，必将进一步加剧这一趋势，因为用户在使用这些应用时将不再需要下载安装客户端（或插件），直接打开支持WebRTC的浏览器即可，这将为用户带来极大的便利性。如果这些通信类应用都提供WebRTC方式的应用支持，将会大大提高服务的可用性——只要有浏览器的地方，用户就可以使用它们的服务，而且会带来新的使用方式和用户体验。

WebRTC可以作为一种全新的VoIP应用形态，催生其他应用向VoIP领域转移和拓展。例如，各种电商、社交类应用，通过对应用平台的增强实现WebRTC支持，这样用户之间可以直接在Web页面上发起VoIP呼叫，把原有的服务能力自然延伸到VoIP领域，提供更为丰富和全面的用户体验。

从产业发展的情况看，目前已经有众多著名互联网厂商投入WebRTC技术研究和规范制定领域，更多的厂商潜心研究WebRTC已经公开的技术和代码，并在此之上开发各式各样的应用，可以预见，将来基于Web的通信会广泛出现在各类互联网应用之中，而这必将对运营商的通信业务带来深远的影响。

从产业发展看，以Skype为代表的OTT VoIP应用对运营商通信业务带来巨大的业务分流和替代已经是大势所趋，而WebRTC技术所带来的便利性和新的用户体验也必将极大地促进这一趋势的发展，从而侵蚀运营商的语音业务。与此同时，WebRTC的兴起也给运营商带来更多的机遇，具体如下：

·WebRTC带动互联网语音和视频应用的发展，为运营商带来巨大的数据流量，并拉动接入需求的增长；

·WebRTC用户成为运营商的潜在客户，运营商可以通过与WebRTC的互通获得更多的呼入呼出话务量，从而扩大营收规模；

·借助WebRTC技术，可以开发新的业务形式和解决方案，如使用户从任意支持浏览器的设备上接入运营商网络。

2.2 与IMS的关系

WebRTC自推出以来就受到了广泛关注，特别是与IMS关系的话题。事实上，两者在服务能力、主要技术等方面有很多共同点，主要体现在如下几个方面：

·提供基于IP的基本语音、视频服务；

·在控制面有很多技术相通，如呼叫状态处理、终端保活、呼叫连续性等，媒体协商也基本一致（WebRTC还需要考虑呼叫状态保存）；

·语音、视频编解码技术以及回声消除、纠错、码率适应算法等方面，可以共用 （出于规范定义的原因，IETF RTCWeb工作组对必须支持的语音、视频编解码和3GPP规范对IMS的要求存在很大不同）；

·NAT和防火墙穿越方面，采用相同的ICE技术（IMS还有ALG（application layer gateway）方式的解决方案）。

从产品定位看，WebRTC技术定位于为双方或者多方基于Web浏览器直接进行实时交互式沟通，而IMS则为电信用户提供多媒体通信（multimedia telephony）服务，需要遵循原有通信业务和各种管制法规的要求，而WebRTC则没有这些约束，这也从本质上决定了两者必然存在的差异，两者对比见表1。

除此之外，两者还有很多细节上的区别，如语音编码方面，WebRTC只有G.711和Opus是必需的，而IMS则要求支持几乎所有传统电话网的编码；媒体路由方面，IMS路由需要经过核心网，而WebRTC则可以是完全点对点的。另外，IMS作为基础电信服务面向普遍的有通信需求的用户，接入方式既包括智能终端，也包括其他各种类型的终端，如传统电话、手机、IAD（integrated access device）、SIP话机等，如果WebRTC期望把服务延伸到电信用户领域，也需要考虑与IMS的互联互通。同样的，IMS也可以引入WebRTC的技术成果，以提高服务的便利性和扩展用户规模。

2.3 WebRTC技术典型应用

需要指出的是，虽然WebRTC的目标是提供基于浏览器的点对点语音、视频等业务，但其使用方式并不能完全局限于浏览器，其应用方式主要包括如下几种。

·基于浏览器的应用，浏览器必须支持WebRTC，服务器提供呼叫控制。浏览器与服务器之间以HTTP或Web Socket交互。

·在本地应用中使用WebRTC，即应用客户端集成WebRTC能力，与网络侧的服务器以XMPP、SIP等协议交互。有很多原有的VoIP类应用都是通过这种方式改造使用WebRTC的一些技术成果。

3 WebRTC与IMS的结合

经过前面的对比和分析，WebRTC与IMS有着很多区别，但两者并不是对立的，而是有着各自的应用场合，能够相互补充和结合。从IMS角度看，与WebRTC的结合主要有3种方式：利用WebRTC接入、与WebRTC互通和与WebRTC融合。

3.1 WebRTC接入IMS

传统的IMS客户端包括硬终端和软终端，WebRTC的出现使得单纯基于浏览器的IMS客户端成为可能。WebRTC浏览器提供了对本地麦克和摄像头的访问功能，封装了媒体面所需要的能力，包括语音、视频编解码和NAT穿越等。

以WebRTC方式接入IMS的系统架构如图2所示，需要部署WebRTC接入网关连接到IMS网络。WebRTC接入网关提供IMS应用逻辑，包括用户鉴权、呼叫控制等。媒体面需要有媒体服务器提供NAT穿越、转码等功能。IMS用户通过支持WebRTC的浏览器连接到接入网关并以HTTP/Web Socket交互，首先实现用户鉴权。鉴权通过后，在用户UI上显示拨号盘或者通讯录列表供用户发起和接收呼叫。呼叫建立的过程中，通过调用JavaScript API建立起媒体面连接，经由媒体服务器转接与IMS网络建立媒体流。

表1 IMS与WebRTC的对比

这一方案应用于运营商为IMS用户提供Web方式登录使用IMS业务的场景，即用户首先是运营商的用户。带来的好处是显而易见的，用户不需要安装或购买专用的客户端即可使用IMS服务。由于是通过浏览器方式访问WebRTC接入网关，免去了终端软件升级带来的烦恼。鉴权时所使用的身份信息与通过其他方式登录IMS一致。使用业务时如何处理与其他IMS终端的关系，可以由运营商的策略来控制。

3.2 IMS与WebRTC互通

IMS用户和WebRTC用户之间相互进行语音、视频通话的场景，即两个用户分别属于IMS网络和WebRTC网络，由一端发起与另一端的通话。WebRTC呼叫服务平台与IMS之间通过IMS与WebRTC的互通网关连接，如图3所示。

图3中WebRTC用户通过浏览器接入WebRTC服务平台。IMS用户接入IMS网络，没有在图3中画出，两个用户分别在各自的服务平台鉴权。进行互通时，WebRTC平台和IMS都需要进行增强，增加呼叫路由规则。当WebRTC用户发起呼叫时，WebRTC平台需要判别该用户为IMS用户，路由呼叫到WebRTC互通网关，WebRTC网关向该IMS用户标识发起呼叫，然后按照IMS的规则进行呼叫处理，反之亦然。需要说明的是，此时WebRTC互通网关与IMS网络之间通过NNI（network to network interface）交互，交互的网元可以是I-CSCF或SBC（session border controller）。为了NAT穿越的需要，WebRTC用户的媒体流可能需要经过中间节点（如TURN服务器）中转，具体与网络部署有关。

3.3 IMS与WebRTC融合

在这种场景下，用户同时归属于WebRTC用户和IMS用户，用户既可以在WebRTC平台发起和接收呼叫，也可以在IMS网络发起和接收呼叫，甚至可以在呼叫过程中在两个域之间切换。这种方式对用户而言有极大的自主性，可以根据偏好在不同的时候采用不同的服务。比如，网络条件好时采用WebRTC服务，条件变差时切换到IMS服务，或者设置在国际漫游时自动切换到WebRTC服务，以节省资费。对于这种场景的研究目前比较少，实现起来也比较复杂，需要对WebRTC和IMS网络都进行更多的增强并引入类似IMS VCC的能力，在这里不做详细介绍。

4 主要研究方向

WebRTC作为一项发展中的技术，仍然有很多问题处于研究之中或有待研究，主要包括以下几个方面。

·呼叫建立过程中的状态保存问题，包括呼叫的会话状态、媒体描述信息和ICE协商状态，浏览器刷新可能导致这些状态信息丢失，目前考虑的方式是封装成对象保存到服务器端，在完成信息保存的同时，又避免了API的复杂化。

图2 用户以WebRTC方式接入IMS

图3 IMS与WebRTC互通

·呼叫相关的协议和流程定义，包括对呼叫分支的处理，如串振、并振等方式以及SDP扩展和交互过程，协议的扩展目前由IETF RTCWeb工作组协同MMUSIC工作组进行。

·QoS。对于提供DiffServ的网络，通过定义不同媒体流（音频、交互式视频、非交互式视频、数据）的优先级提高QoS。

·WebRTC的安全。WebRTC的安全威胁是显而易见的。由于浏览器提供了对本地资源的访问，一个恶意的Web站点可能在用户毫无察觉的情况下启动本地摄像头、麦克风等侵犯用户的隐私，或者冒充某个用户的身份发起呼叫而难以识别。另外，屏幕共享时，Web站点通过JavaScript代码可能窃取超出用户共享范围的内容。

·IMS用户以WebRTC方式接入，提供用户的鉴权、计费、紧急服务以及合法监听等业务。

·WebRTC与IMS互通。

·WebRTC 与 PCC（policy and charging control）结合 ，以提高QoS和管控能力。

此外还有一些技术问题等待探索，如HTTP-only型NAT/防火墙的穿越、WebRTC紧急服务和合法监听的提供等。

5 结束语

在这个一切走向Web的时代，WebRTC以其极大的便利性必将获得长足的发展。从现有的态势看，传统客户端方式的VoIP应用都纷纷推出对WebRTC的支持。各个主流的浏览器厂商对WebRTC的支持更是亦步亦趋。WebRTC的开源和对通信能力的封装大大降低了VoIP应用的开发难度，应用开发者不需要具备专门的VoIP经验就可以开发出专业的WebRTC应用，这将促进互联网化的VoIP应用能力的蓬勃发展。而WebRTC使用的便利性使得用户可以随时利用此类应用发起语音、视频呼叫或者文件共享，因此VoIP用户规模也会迅速扩大。一方面，这种趋势会对运营商的通信类业务带来极大的影响；另一方面，VoIP应用的普及和用户群的扩大也有利于运营商扩大服务范围和话务流量，也会带来可观的数据流量。无论是引入WebRTC技术到运营商业务中，还是与WebRTC互通，都会为运营商带来更多的价值。也许未来会形成以运营商通信业务为代表的、受控的VoIP生态系统和一个以WebRTC为代表的OTT VoIP的生态系统共存的局面。前者服务于有QoS保障、高可靠性、提供普遍服务和全球互通的用户群体，后者服务于互联网化、低成本的有通信需求的用户群体，两者之间的互联实现更大规模的互联互通。

1 WebRTC.http://www.webrtc.org

2 W3C HTML5.http://www.w3.org/TR/html5/

3 W3C WebRTC Workgroup.http://www.w3.org/2011/04/webrtccharter.html

4 W3C WebRTC API.http://dev.w3.org/2011/webrtc/editor/webrtc.html

5 IETF RTCWeb Workgroup.http://tools.ietf.org/wg/rtcweb/charters

6 3GPP TR 23.701.Study on the Support of WebRTC IMS Client Access to IMS,2010

7 IETF RFC5245.ICE (interactive connectivity establishment).http://tools.ietf.org/html/rfc5245,2010

8 IETF RFC5389.STUN(session traversal utilities for NAT).http://tools.ietf.org/html/rfc5389,2008

9 IETF RFC5766.TURN (traversal using relays around NAT).http://tools.ietf.org/html/rfc5766,2010

10 IETF RFC6716.Opus(definition of the opus audio codec).http://tools.ietf.org/html/rfc6716,2013

11 IETF RFC3261.SIP(session initiation protocol).http://tools.ietf.org/html/rfc3261,2002

12 IETF RFC3264.SDP (session description protocol).http://tools.ietf.org/html/rfc3264,2010

13 IETF RFC6455.The Web socket protocol.http://tools.ietf.org/html/rfc6455,2011