林 鴻，王 松，楊 鑫，付 斌

（1.法國電信北京研發(fā)中心 北京 100190；2.中國電信股份有限公司北京研究院 北京 100035）

1 引言

WebRTC[1]（Web real-time communication，Web 實時通信）是一項在瀏覽器內部進行實時視頻和音頻數據通信的技術，是HTML5[2]標準之一。Web 2.0在過去的幾年里將可編程性和交互性嵌入瀏覽器，而不只是顯示靜態(tài)內容和格式。但是，Web技術還不能夠應付實時雙向的語音和視頻通信需要。使用如Adobe的flash瀏覽器插件有明顯的靈活性和性能等方面的限制。通過WebRTC技術可以開發(fā)具有實時音視頻通信的Web應用，利用其核心實現(xiàn)還可以開發(fā)出具有實時音視頻通信的移動應用。在這些基礎應用上，結合其他的先進技術，可以開發(fā)出更多創(chuàng)新的Web和移動應用。

2 WebRTC主要技術特點

如圖1所示[1]，在WebRTC系統(tǒng)架構中，包括面向Web應用開發(fā)者的Web API和WebRTC核心庫。WebRTC核心庫包含語音引擎 (voice engine）、視頻引擎（video engine）、傳輸層、會話管理（session management）和 C++API，它們都內嵌在瀏覽器里。

Web應用開發(fā)者可以調用標準的JavaScript API開發(fā)基于WebRTC的應用，主要包括：GetUserMedia API用于控制本地設備的接入，如設備上的攝像頭和麥克風，也叫MediaStream API；PeerConnection API用于管理在兩個瀏覽器之間雙向媒體流的發(fā)送和接收，通過JSEP（JavaScript session establishment protocol，JavaScript會話建立協(xié)議）[3]實現(xiàn)媒體參數的協(xié)商，這是WebRTC最典型的P2P應用場景；DataChannels API用于瀏覽器之間發(fā)送和接收非多媒體的數據流。

在WebRTC核心庫中，語音引擎實現(xiàn)了從聲卡到網絡整個音頻媒體鏈的技術框架，包括對語音的聲學處理以及iSAC、iLBC和Opus音頻編解碼的實現(xiàn)。視頻引擎實現(xiàn)了從攝像頭到網絡、從網絡到屏幕整個視頻媒體鏈的技術框架，還包括視頻圖像的處理和VP8視頻編解碼的實現(xiàn)。會話控制是為支持呼叫建立和管理的抽象會話層，應用開發(fā)者決定如何實現(xiàn)具體協(xié)議。C++API是瀏覽器廠商實現(xiàn)Web API所需的函數集。

在傳輸層中，WebRTC利用 ICE[4]/STUN[5]/TURN[6]機制來建立不同類型網絡間的呼叫連接，解決NAT穿越問題。WebRTC通過RTP傳輸音頻和視頻媒體流，通過SCTP實現(xiàn)傳輸可靠數據流。90%左右NAT類型均可以利用STUN獲得對方的公網IP地址和端口，實現(xiàn)穿越，不需要媒體服務器進行中繼。只有10%左右NAT為對稱性NAT，可以采用在互聯(lián)網上部署TURN中繼服務器的方式實現(xiàn)NAT穿越?？梢?，WebRTC技術不同于傳統(tǒng)的SIP/IMS網絡部署，在不考慮監(jiān)管等因素的情況下，大大降低了媒體服務器的負載和部署成本。

WebRTC技術主要優(yōu)點如下。

（1）開放的標準

WebRTC是HTML5標準之一，也是由W3C和IETF標準組織共同定義的一個開放的標準。W3C的WebRTC工作組[7]為Web開發(fā)者定義了基于瀏覽器的Web API[8]用于開發(fā)具有語音、視頻和數據功能的Web應用。而IETF的RTCWeb工作組[9]定義了瀏覽器之間媒體流交互的協(xié)議和規(guī)范，但沒有定義呼叫控制協(xié)議。3GPP也正在制定WebRTC和IMS之間互聯(lián)需求（TR 23.701[10]）的標準。

（2）簡單和易擴展性

WebRTC提供了一個簡單可擴展的技術框架和方案選型，方便開發(fā)者通過互聯(lián)網提供語音、視頻和數據等多種應用和服務。WebRTC本身并不定義同用戶之間的交互方式、媒體流的路由方式、用戶身份認證、呼叫協(xié)議和控制以及同其他網絡的互聯(lián)方式等。這些課題由開發(fā)者和服務提供商根據不同的業(yè)務場景和技術需要進行靈活選擇和配置。

（3）來自產業(yè)鏈的廣泛支持

WebRTC技術獲得來自產業(yè)鏈的支持。除了瀏覽器廠商，如 Google、Mozilla和 Opera外，其他大公司在 WebRTC上也表現(xiàn)積極，如運營商AT&T、Telefonica，設備商Alcatel Lucent、Ericsson、Cisco、Avaya、Acme Packet等 以 及 來 自 從企業(yè)通信到游戲等領域的眾多開發(fā)者和初創(chuàng)公司。許多圍繞WebRTC技術的工作在美國、歐洲和亞洲，特別是在中國和韓國，都在積極進行之中。

（4）同運營商網絡的互聯(lián)互通

WebRTC的一些應用場景可以作為運營商既有業(yè)務和網絡的有效補充，比如通過WebRTC提供IMS服務、會議和呼叫中心的升級、企業(yè)統(tǒng)一通信業(yè)務的改進等以及一些垂直業(yè)務的擴充，如M2M、教育和醫(yī)療等。

（5）和其他技術的結合

WebRTC技術容易和其他的先進技術，如虛擬現(xiàn)實、手勢控制、人臉識別等技術結合，實現(xiàn)Web應用的快速mash-up開發(fā)和實現(xiàn)。

3 基于WebRTC技術的移動客戶端和Web應用的技術

基于WebRTC的Web API能夠比較容易開發(fā)支持實時語音視頻通信及數據可靠通信的Web應用以及基于這種基本能力的其他Web應用。但是這種Web應用還存在一些實際問題。比如，如何在瀏覽器中通知用戶來電問題，一般情況下，瀏覽器處理呼入電話總是比出站連接更難。這種情況在手機上更復雜，來電通知可能需要常規(guī)的鈴聲，而不是簡單的提示；如果用戶已經處于一個CS或者VoIP通話，如何提示和區(qū)別這個WebRTC的來電是需要探討的問題。另外，用戶如果在呼叫中刷新了網頁，這時JavaScript執(zhí)行的上下文發(fā)生重置，會話中間狀態(tài)會丟失。這些是Web應用實現(xiàn)實時通信需要解決的問題。

除了利用Web API開發(fā)Web應用外，利用WebRTC核心庫也可以開發(fā)出具有實時通信功能的移動客戶端。WebRTC核心庫具有如下特點。

（1）支持多種開源音視頻編解碼

音頻編解碼中支持iSAC、iLBC、Opus等免費音頻編解碼和VP8視頻編解碼。iSAC是一種用于VoIP和流音頻的寬帶和超寬帶音頻編解碼器。iLBC是用于VoIP和流音頻的窄帶語音編解碼器。其標準由IETFRFC3951[11]和RFC3952[12]定義。Opus支持持續(xù)和可變碼流編解碼。其標準由IETFRFC6716[13]定義。VP8基于WebM 項目[14]，非常適合低時延的視頻通信。

（2）具有強大的音視頻引擎

WebRTC語音引擎支持自適應抖動控制算法和語音分組丟失隱藏算法，用于緩解網絡抖動和分組丟失引起的負面影響，使其能夠快速且高解析度地適應不斷變化的網絡環(huán)境，確保音質優(yōu)美且緩沖時延最小，提高語音通話質量；支持基于軟件的信號處理來消除回聲，實時地去除手麥克風采集到的回聲；支持基于軟件的信號處理來抑制噪聲，用于消除與相關語音通話中某些類型的背景噪聲。動態(tài)抖動緩存和錯誤隱藏算法，用于緩解網絡抖動和分組丟失引起的負面影響。視頻引擎支持視頻動態(tài)抖動控制，緩解抖動和分組丟失引起的負面影響，有助于提升整個視頻的通信質量；支持圖像增強，去除從攝像頭抓取圖像的噪聲。

（3）支持多移動平臺

WebRTC核心庫可以移植到不同的移動平臺，如Android、iOS、Windows Phone等。

（4）核心技術獲業(yè)界認可

WebRTC語音引擎如前所述來自Global IP Solutions公司[15]。許多大公司的產品，如 Skype、QQ、WebEX、AOL 等都曾采用該公司的IP語音引擎和相關產品。

所以，通過增加用戶管理、會話協(xié)議控制和用戶交互界面等工作，結合這個WebRTC核心庫就可以開發(fā)跨平臺的實時音視頻通信的移動互聯(lián)網應用。美國上市公司Vonage，也開始考慮充分利用WebRTC的核心庫開發(fā)Android和iOS移動平臺的客戶端應用，減少對私有和付費技術方案的依賴。

4 基于WebRTC技術的移動客戶端和Web應用的參考設計和實現(xiàn)

使用統(tǒng)一的服務平臺支持移動客戶端和Web應用。服務平臺提供一組標準的客戶端API，方便移動客戶端和Web應用調用，實現(xiàn)服務平臺和前端應用的松耦合。目前大部分基于WebRTC的服務都部署在GAE（Google App engine）上，用戶之間P2P通道的建立以及呼叫信令的傳輸，都是通過GAE完成。但是GAE環(huán)境國內不能訪問。筆者基于開源軟件項目部署自己的應用服務器，實現(xiàn)了基于WebRTC的服務。

WebRTC沒有定義用戶呼叫管控制協(xié)議。SIP、XMPP[16]、其他標準協(xié)議或者完全私有協(xié)議都可以用于呼叫控制協(xié)議。SIP是最常用的VoIP，廣泛用于企業(yè)的IPPBX和運營商的IMS平臺。采用XMPP/Jingle[17]用于呼叫控制，主要基于以下幾點考慮：XMPP本身比SIP更簡單；客戶端協(xié)議棧實現(xiàn)和JavaScript實現(xiàn)更輕量；XMPP后臺處理不需要安裝類似SBC網關做NAT穿越；沒有同IMS網絡互通的需求等。

下面分別詳細描述基于WebRTC技術的移動客戶端、Web應用和支持它們的服務平臺的設計及具體實現(xiàn)。

4.1 移動客戶端設計與實現(xiàn)

基于WebRTC開發(fā)實現(xiàn)了移動客戶端微呼，這是一款支持新浪微博好友之間進行免費語音、文字通信的創(chuàng)新應用。通過調用服務平臺提供的客戶端API和服務平臺交互，包括用戶注冊、登錄、訂閱用戶狀態(tài)、獲取用戶狀態(tài)等。通過XMPP實現(xiàn)用戶之間語音通信時的呼叫建立、信令協(xié)商、會話管理和SDP[18]協(xié)商；通過XMPP實現(xiàn)用戶之間的文字消息的傳遞；通過RTP傳送語音媒體流，RTCP監(jiān)控媒體流傳送質量；通過STUN和TURN協(xié)議來建立不同類型網絡間的媒體鏈接，實現(xiàn)P2P的媒體流傳輸，減少中間媒體服務器的要求。

WebRTC移動客戶端基于Android SDK進行開發(fā)，集成了libjingle和WebRTC兩個開源項目，其中l(wèi)ibjingle庫提供了XMPP的處理和解析等功能，WebRTC庫提供了語音編碼和聲學處理等功能。同時客戶端也集成了友盟SDK的統(tǒng)計功能和新浪微博SDK的相關功能。軟件架構如圖2所示。

其中核心邏輯分層結構如下。

·package com.orange.weihu.activity：用戶交互相關的核心邏輯模塊。

· packagecom.orange.weihu.common：通用數據輔助模塊。

· package com.orange.weihu.component：自定義相關視圖組件模塊。

· package com.orange.weihu.data：數據存儲模塊。

· package com.orange.weihu.jni：JNI(Java native interface)調用接口層。

· package com.orange.weihu.net：網絡處理模塊。

· package com.orange.weihu.service：后臺服務模塊。

· package com.orange.weihu.util：通用輔助模塊。

WebRTC移動客戶端模塊間相互依賴關系如圖3所示。其中，activity包封裝了用戶交互相關的核心邏輯，包括微博認證登錄管理和微博瀏覽展現(xiàn)，用戶的微博好友關系維護和WebRTC好友關系的維護、文本消息的收發(fā)和記錄管理、通話的發(fā)起和接收以及通話記錄的管理。service包封裝底層通話相關庫的核心邏輯，包括共享庫的加載及生命周期管理、開機啟動和微博信息獲取等功能。data包封裝了需要持久化的核心邏輯，包括微博相關信息、好友關系相關信息、文本消息相關信息和通話記錄相關信息。

圖2 WebRTC移動客戶端的軟件架構

WebRTC客戶端中各個模塊調用的基本流程如圖4所示。用戶點擊呼叫按鈕，activity向service傳遞消息，service通過JNI調用libjingle，libjingle設置完成WebRTC相關功能，發(fā)起呼叫。用戶通過微博賬戶登錄，獲得微博好友信息及微博詳情，如果沒有在微呼服務器注冊過，則進行微呼賬戶建立。啟動相關服務，加載底層類庫，建立呼叫相關網絡連接，注冊在線狀態(tài)。選擇在線好友，訪問后臺服務器，獲得好友連接信息，建立通話連接。

4.2 Web應用設計與實現(xiàn)

基于WebRTC的實時語音視頻通信Web應用在無需任何插件的情況下，實現(xiàn)了瀏覽器之間P2P的音頻和視頻通信，提供了Web用戶注冊、登錄、獲取好友在線狀態(tài)以及與在線好友進行實時語音和視頻通話等功能。

Web應用部署在應用服務器 Openfire[19]上，通過JavaScript的方式連接并訪問Openfire服務器。Openfire服務器提供了HTTP綁定的功能，通過7070監(jiān)聽端口，接收Web客戶端發(fā)送的HTTP請求，登錄并訪問服務器。Web應用基于開源JavaScript庫Strophe，是基于JavaScript的可擴展通信和表示協(xié)議（XMPP）客戶端庫，主要功能包括用戶登錄和登出、監(jiān)聽并發(fā)送IM消息、監(jiān)聽服務器推送的presence更新信息、監(jiān)聽服務器轉發(fā)的IQ信息。

Jingle協(xié)議是XMPP的擴展，用于規(guī)范兩個XMPP客戶端之間的信令協(xié)議。SDP信令流程和Jingle信令流程的不同之處在于P2P通道地址和端口的發(fā)送時間，Jingle信令在發(fā)起呼叫時，便會協(xié)商P2P通道地址和端口；而SDP信令將編解碼協(xié)商和P2P通道地址協(xié)商分為兩個信令發(fā)送，在發(fā)送發(fā)起呼叫信令后，便馬上發(fā)送P2P通道地址和端口。WebRTC中的信令是基于SDP格式的，而Openfire應用服務器是基于XMPP的，信令格式基于Jingle協(xié)議，所以需要對信令格式進行轉換，包括SDP信令和Jingle信令的互換，需要將JSEP中的SDP格式映射為Jingle格式[20]。

4.3 服務平臺設計與實現(xiàn)

服務平臺基于XMPP，并以XML數據元流式來傳輸數據，為移動客戶端和PC客戶端提供基于Web的IM傳輸、VoIP呼叫、信令傳輸、用戶管理和用戶關系維護、好友狀態(tài)presence信息推送以及日志統(tǒng)計等功能。

服務平臺的邏輯架構如圖5所示，服務平臺包括XMPP服務器、STUN服務器和TURN服務器。其中XMPP服務器用于即時消息轉發(fā)和實時通信信令傳輸，STUN服務器用于NAT穿越，TURN服務器用于媒體流的轉發(fā)。

圖4 WebRTC移動客戶端的模塊調用基本流程

圖5 服務平臺的邏輯架構

Openfire是基于XMPP、跨平臺的即時消息服務器，支持服務器到服務器的連接，用于部署多個Openfire服務器進行擴展；支持部署多個連接管理器，用于整合到Openfire的客戶端連接，提高Openfire的在線用戶數；提供了一系列的可用插件，并支持插件擴展，即開發(fā)者可通過部署新的plugin，進行功能的擴展。Openfire還作為VoIP通信信令服務器，提供端到端的Jingle信令的協(xié)商和傳輸。

服務本平臺以plugin的方式，對Openfire進行了功能擴展，包括用戶管理和注冊、獲取用戶在線狀態(tài)和通信日志統(tǒng)計等。服務平臺采用不同的協(xié)議與客戶端進行交互：IM傳輸采用XMPP，信令傳輸基于Jingle協(xié)議，對所提供API的訪問采用HTTP。

服務平臺基于STUN和TURN的方式進行NAT穿越。STUN服務器檢測主機的NAT類型，并根據NAT類型，在客戶端進行打洞，以支持兩個客戶端之間的P2P通信。TURN服務器用于解決對稱型NAT的穿越問題。TURN服務器相當于中繼服務器，客戶端獲取TURN的公網IP地址，客戶端之間的通信均通過TURN服務器進行中轉，這對于TURN服務器的性能提出了很高的要求。但基于TURN服務器是對STUN服務器的有效補充，可以滿足性能要求。

Web應用以HTTP綁定的方式登錄并訪問Openfire服務器，但Web客戶端和Openfire服務器處于不同域，涉及瀏覽器JavaScript跨域問題。這就需要Web客戶端調用JavaScript的80端口，并且是同一子域。使用Apache做反向代理，轉發(fā)HTTP-bind請求到XMPP服務器的HTTP-binding端口。

基于安全性的考慮，服務平臺將Openfire服務器部署在內網，并同時配置內網IP地址和外網IP地址，使內網用戶和外網用戶均可訪問。STUN服務器必須部署在公網，并且內置兩個網卡，向外部提供兩個公網IP地址和兩個端口，進行NAT類型的檢測和打洞。TURN服務器也部署在公網，向外部提供一個公網IP地址和端口。Apache反向代理服務器與Openfire服務器部署在同一臺機器上。

5 結束語

本文總結了WebRTC的主要優(yōu)點和技術特點，對分別利用WebRTC技術提供的核心庫和Web API設計和開發(fā)具有實時音視頻通信功能的移動客戶端應用和Web應用進行了技術可行性分析，并詳細描述了筆者基于WebRTC技術開發(fā)移動客戶端應用、Web應用和服務平臺的參考設計和實現(xiàn)。

在不同的移動網絡環(huán)境（3G網絡和Wi-Fi網絡）和不同的Android智能手機上對所開發(fā)的WebRTC移動客戶端進行測試，發(fā)現(xiàn)WebRTC核心庫對網絡時延、噪音抑制和回聲消除都有較好的處理，能在不同網絡環(huán)境中獲得較好的語音質量。在固定寬帶和PC上測試WebRTC的Web應用，除了較好的聲音質量，VP8也能很好地處理視頻信息。當然，還需要在更多環(huán)境和條件下對WebRTC技術進行測試，對測試結果進行系統(tǒng)客觀的分析，更好地評價WebRTC技術在音視頻通信服務中的技術成熟度。

WebRTC移動客戶端和Web應用還有很大的改進空間。比如，客戶端可以根據不同的網絡環(huán)境動態(tài)調整編解碼，在iSAC、iLBC和Opus編解碼中自動選擇適合當前網絡環(huán)境的最優(yōu)編解碼和技術參數。視頻編解碼VP8和H.264在不同網絡環(huán)境下的性能對比也值得進一步的深入研究。WebRTC移動客戶端目前只支持Android移動平臺，可以將WebRTC核心庫移植到其他移動平臺上，客戶端可以支持更多的操作系統(tǒng)。也可以將WebRTC核心庫和移植部分封裝為SDK，供移動應用開發(fā)者開發(fā)各種具有實時通信能力的移動客戶端。Web應用同移動客戶端之間的互聯(lián)也值得進一步的研究和實現(xiàn)。在WebRTC技術中，目前還沒有進一步挖掘的能力和對數據流的支持，包括Web API中的數據信道的使用和WebRTC核心庫中對應但還未出現(xiàn)的數據流引擎。

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

2 W3C HTML5.http://www.w3.org/TR/htm l5/

3 IETF RTCWeb JSEP.JavaScript session establishment protocol.http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/，2013

4 IETF RFC5245 ICE.Interactive Connectivity Establishment,2010

5 IETF RFC5389 STUN.Session Traversal Utilities for NAT,2008

6 IETF RFC5766 TURN.Traversal Using Relays around NAT,2010

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

8 W3CWebRTC API.http://dev.w3.org/2011/webrtc/editor/webrtc.html

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

10 3GPP TR 23.701.Study on the Support of WebRTC IMS Client Access to IMS，2013

11 IETF RFC3951 iLBC.Internet Low Bit Rate Codec,2004

12 IETF RFC3592 RTP iLBC.RTP Payload Format for Internet Low Bit Rate Codec Speech,2004

13 IETF RFC6716 Opus.Definition of the Opus Audio Codec,2012

14 WebM project.http://www.webmproject.org/

15 Global IP solutions.http://zh.wikipedia.org/wiki/Global_IP_Sound

16 IETFRFC6120XMPP.ExtensibleMessagingand PresenceProtocol

17 XMPPXEP-0166 Jingle.http://xmpp.org/extensions/xep-0166.html

18 IETF RFC3264 SDP.Session Description Protocol,2002

19 Openfire.http://www.igniterealtime.org/projects/openfire/

20 IETF RTCWeb JSEP XMPP/Jingle mapping.http://datatracker.ietf.org/doc/draft-li-rtcweb-jsep-xmpp-mapping/