宋瑞

【摘 要】WebRTC因其開放的標準、簡單易擴展、同運營商網(wǎng)絡的互聯(lián)互通、與其他技術(shù)結(jié)合等特性，本文旨在通過對W3C WebRTC標準的跟蹤和業(yè)界WebRTC開源項目的系統(tǒng)分析，梳理出WebRTC應用所涉及的關(guān)鍵技術(shù)。

【關(guān)鍵詞】WebRTC； 通訊系統(tǒng)；瀏覽器；

WebRTC（Web Real-Time Communication）Web上的實時通信，泛指基于網(wǎng)頁的實時通信業(yè)務，如電話、視頻會議、即時消息等。WebRTC項目的主要目的是讓Web開發(fā)者不用其他的軟件就能夠便利的開發(fā)出實時的，基于瀏覽器的多媒體應用，Web開發(fā)者也無需對多媒體的數(shù)字信號處理過程過多在意，只需簡單的Javascript和HTML5技術(shù)即可即可實現(xiàn)。WebRTC基于標準的WHATWG協(xié)議，給予了視頻會議的核心技術(shù)，包括音視頻的采集、編解碼、網(wǎng)絡傳輸、顯示等功能，并且還支持跨平臺：windows，linux，mac，android。

1.業(yè)界WebRTC原型概況

1.1業(yè)界WebRTC

（1）官方demo

沒有用任何封裝庫，信令機制使用了XHR和Google App Engine Channel API，可實現(xiàn)瀏覽器間的視頻音頻通信。

（2）愛立信實驗室開發(fā)的WebRTC demo

這是第一個基于瀏覽器的WebRTC視頻通信demo，愛立信為此還開發(fā)了一個基于WebKit的瀏覽器用于支持WebRTC，叫做Bowser browser（當時市場上可能還沒有支持WebRTC的瀏覽器）。

（3）華為WebRTC

華為WebRTC網(wǎng)絡并不僅僅著眼于WebRTC用戶系統(tǒng)，而是秉持CAAS（Communication as a Service）的核心理念，開發(fā)使用簡單，作為其WebRTC能力開放網(wǎng)關(guān)地關(guān)鍵足點。

1.2業(yè)務流程分析

（1）向Participations UA返回成功將其加入會議室roomName的消息，ParticipationUA收到消息后添加本地的視頻流到指定位。

（2）向Host UA廣播Participations UA加入到會議室roomName的通知，廣播消息中包含Participations UA的標識。

（3）Host UA在收到Signaling Server廣播Participations UA加入到會議室roomName的通知后，會著手進行兩個方面的工作。

（4）發(fā)起與Participation UA的媒體協(xié)商：首先獲取并保存本地的媒體面信息offer，并途經(jīng)Signaling Server路由轉(zhuǎn)發(fā)給ParticipationsUA。Participations UA收到offer后，保存Host UA的媒體面信息并據(jù)此創(chuàng)建協(xié)商媒體信息answer，最后將answer途經(jīng)Signaling Server路由轉(zhuǎn)發(fā)給Host UA。

至此，Host UA與Participations UA之間已可以進行端到端的視頻通話。

2.多方視頻會議系統(tǒng)設計與實現(xiàn)

2.1 設計方案

WebRTC標準Javascript接口由瀏覽器提供，客戶端與服務端雙向通信采用WebSocket（客戶端由瀏覽器提供支持，服務端由tomcat提供支持），jain-sip采用Mobicents開源的JavaScript庫來提供SIP棧的支持。WebRTC封裝庫建立在WebRTC和jain-sip的基礎上，它利用jain-sip提供的SIP棧功能組裝SIP請求并經(jīng)過瀏覽器提供的WebSocket傳輸給服務端。

WebRTC封裝庫的主要功能如下：屏蔽不同瀏覽器廠商在WebRTC標準接口實現(xiàn)上的差異（包括接口命名差異和方法調(diào)用差異）；將客戶端與服務端之間雙向通信連接建立機制以及通信的細節(jié)，做到向上層Web應用開發(fā)者透明；在端到多端的媒體協(xié)商以及防火墻穿越機制上，做到向開發(fā)者透明。

2.2 關(guān)鍵技術(shù)

2.2.1 SIP信令交互技術(shù)

在W3C WebRTC標準中，對客戶端與服務端之間的信令沒有具體的標準。SIP以其簡易、靈巧和可伸展等特性，得到越來越多的關(guān)注和贊同，已成為下一代Web通信事實上的規(guī)范。正是基于這樣一種特點，本項目開發(fā)以SIP為核心的WebRTC視頻通信系統(tǒng)。為完成客戶端與服務端SIP信令交互，本系統(tǒng)在客戶端側(cè)使用其對JAIN-SIP標準的參考實現(xiàn)來提供SIP棧服務，服務端側(cè)利用SIP Servlet API來處理客戶端側(cè)請求或進行路由分發(fā)，客戶端與服務端之間的雙向通信采用了WebSocket協(xié)議。在本系統(tǒng)中，服務端實際上就是充當個背靠背代理的角色。

2.2.2 多方媒體協(xié)商技術(shù)

多方媒體協(xié)商與防火墻穿越協(xié)議機制是實現(xiàn)WebRTC多方視頻會議的關(guān)鍵所在。在具體的實現(xiàn)策略上，WebRTC封裝庫將多方的協(xié)商過程分解成多個端到端的協(xié)商過程，可通過后入會者發(fā)起來實現(xiàn)。這里簡要描述一下后入會者協(xié)商的過程：

（1）第一方與第二方情形下，由一對PeerConnection對象來完成offer/answer的協(xié)商。主動協(xié)商的一方PeerConnection利用接口createOffer獲取到本方的媒體面相關(guān)信息后，將該信息通過信令服務器傳送到對端。對端的PeerConnection對象保存該信息，并利用接口createAnswer獲取當?shù)氐拿襟w面信息，并將其通過信令服務器回傳給主動協(xié)議的一方。這樣，兩方之間的協(xié)商完成。

（2）當?shù)谌郊尤霑h時，應用程序會創(chuàng)建兩個PeerConnection對象，一個用來與第一方進行協(xié)商，另一個用于與第二方進行協(xié)商。第二方和第三方在收到第一方對應的PeerConnection對象發(fā)送過來的offer信息后，將分別創(chuàng)建一個新的PeerConnection對象來負責與之交互，并按照1）所述的方法完成與第三方的媒體協(xié)商過程。

2.2.3 NAT/防火墻穿越技術(shù)

這種技術(shù)是把內(nèi)部網(wǎng)絡（簡稱為內(nèi)網(wǎng)）私有IP地址轉(zhuǎn)變?yōu)橥饩W(wǎng)公共IP地址，它使得局域范圍內(nèi)的多臺主機利用同一個公共IP地址就可以連接到外網(wǎng)。一方面，NAT技術(shù)可以在很大程度上緩解了公網(wǎng)IP地址緊缺的問題，并有效減少了內(nèi)網(wǎng)主機受外部系統(tǒng)攻擊的可能性。另一方面，對于WebRTC等Web音視頻通信而言，NAT的應用會致使其在跨局域網(wǎng)的環(huán)境中失效。這是因為，位于局域網(wǎng)的主機無法在公網(wǎng)上進行路由，進而無法完成不同局域網(wǎng)內(nèi)部主機相互之間的P2P通信。

3.多方視頻會議系統(tǒng)性能測試與分析

3.1環(huán)境搭建

3.1.1下載安裝jdk

進入oracle官網(wǎng)downloads專區(qū)，選擇下載版本jdk-6u13-windows-i586-p.exe，雙擊運行即可安裝。

3.1.2配置jdk環(huán)境變量

在控制面板系統(tǒng)和安全系統(tǒng)高級系統(tǒng)設置環(huán)境變量系統(tǒng)變量中新建環(huán)境變量JAVA_HOME并設置成下面的格式，找到Path和CLASSPATH分別設置成如下所示的格式。JAVA_HOME

C：＼Program Files＼Java＼jdk1.6.0_13

Path

%SystemRoot%＼system32；%SystemRoot%；%SystemRoot%＼System32＼Wbem；%SYSTEMROOT Server＼110＼Tools＼Binn＼；E：＼Project＼opencv＼build＼x86＼vc11＼bin；%JAVA_HOME%＼bin；

CLASSPATH

%JAVA_HOME%＼lib＼dt.jar；%JAVA_HOME%＼lib＼tools.jar；

3.2 核心流程

在服務端側(cè)，處理“創(chuàng)建會議”和“加入會議”的邏輯實際上也是作為兩個分支集成在同一個大的處理邏輯當中（SIP Servlet里面的doSubscribe），為了區(qū)別兩者不同的請求，我們事先約定按照客戶端SUBSCRIBE請求頭部里面的Expires的整型值來確定：當請求中的Expires為3600時，是創(chuàng)建會議的請求，當請求中的Expires值為1800時，是加入會議。

用戶加入會議成功后，服務端返回的信息，顯示本地視頻流用的是HTML5的getUserMedia接口。當然，獲取到這個媒體流Stream后，還需要借助HTML5 URL接口將其轉(zhuǎn)換成url，然后再添加到HTML5

PeerConnection是WebRTC的標準接口，用于建立與遠端瀏覽器的連接，W3C標準里面。Offer和answer是一對JSEP SDP格式的媒體協(xié)商信息。其中，offer由主動發(fā)起協(xié)商的一方的PeerConnectioncreateOffer創(chuàng)建。在保存本地媒體面信息（PeerConnection.setLocalDescription（offer））后，將其作為INVITE請求的內(nèi)容經(jīng)服務端轉(zhuǎn)發(fā)至協(xié)商的對方。對方在收到offer后，創(chuàng)建一個對應的PeerConnection對象并保存該信息（PeerConnection.setRemoteDescription（offer））。然后，創(chuàng)建協(xié)商的媒體信息answer（PeerConnection.createAnswer）返回給主動發(fā)起協(xié)商的一方（作為SIP 200 OK響應的內(nèi)容）。主動發(fā)起協(xié)商的一方收到后保存answer.至此，完成端到端的媒體協(xié)商過程。

3.3連通性測試

在offer/answer里面，除了音視頻編解碼信息之外，還有用于做連通性測試的ice-candidates。Ice-candidates是ICE客戶端（集成在WebRTC當中）從ICE Server獲取到的。

在ice-candidates里面，包括三類地址：本地地址（local ip + local port）、NAT對外映射的地址和端口（NAT ip + NAT port，由ICE服務器返回）以及中繼地址和端口（TURN ip + TURN port，由ICE服務器返回）。

當通信的雙方通過offer/answer對獲取到對端的ice-condidates后，會按照優(yōu)先級組合并進行連通性測試。與此同時，對端也會按照同樣的組合方式進行連通性測試。

4.結(jié)論

作為一種新興的技術(shù)，WebRTC在最大程度上簡化了網(wǎng)絡即時通信的復雜程度，它第一次讓Web音視頻通信等過去必須由專業(yè)人員才能實現(xiàn)的插件功能離普通的Web開發(fā)者如此之近。WebRTC在技術(shù)上和標準上也都取得了長足的進步。

參考文獻：

[1] 林鴻， 王松， 楊鑫，付斌. 基于WebRTC技術(shù)的應用及平臺技術(shù)開發(fā)與設計[J]. 電信科學， 2013， 29（9） ：20-25.

[2] Justin Uberti， Cullen Jennings. Javascript Session Establishment Protocol. 22 October 2013. Active Internet-Draft[EB/OL]. http：//http：//datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/

[3] 屈振華， 李慧云， 張海濤， 龍顯軍. WebRTC技術(shù)初探[J]. 電信科學， 2012， 28（10） ：106-110.

[4] 胡敏， 劉六程， 劉鵬. 基于WebRTC的視頻會議系統(tǒng)的設計與實現(xiàn)[J]. 電視技術(shù).