1. 前言

　　WebRTC（Web Real-Time Communication——網(wǎng)頁實(shí)時通信）是一個基于瀏覽器的實(shí)時多媒體通信技術(shù)。該項技術(shù)旨在使Web瀏覽器具備實(shí)時通信能力；同時，通過將這些能 力封裝并以JavaScript API的方式開放給Web應(yīng)用開發(fā)人員，使得Web應(yīng)用開發(fā)人員能夠通過HTML標(biāo)簽和JavaScript API快速地開發(fā)出基于Web瀏覽器的實(shí)時音視頻應(yīng)用，而無需依賴任何第三方插件。該項技術(shù)將Web瀏覽器打造成一個適用于在所有用戶設(shè)備（比如移動智能 終端和個人電腦等）間進(jìn)行實(shí)時的音視頻和數(shù)據(jù)通信的通用平臺。

　　在WebRTC技術(shù)出現(xiàn)之前，基于Web瀏覽器的多媒體通信服務(wù)是構(gòu)建在特定的瀏覽器插件（如Adobe Flash Player）之上的，因?yàn)闉g覽器所依賴的HTTP協(xié)議是一種無連接狀態(tài)的協(xié)議——即瀏覽器與服務(wù)器建立連接，下載文件，斷開連接，再顯示接收到的文件。 因此，瀏覽器不能與服務(wù)器實(shí)時動態(tài)地交換數(shù)據(jù)。無連接狀態(tài)的HTTP協(xié)議導(dǎo)致需要實(shí)時通信的服務(wù)（如聊天等）只能采取定時訪問服務(wù)器的方法（即輪詢方式） 來實(shí)現(xiàn)。然而，在用戶訪問量增多時，這種方式嚴(yán)重的消耗服務(wù)器端資源，進(jìn)而嚴(yán)重的影響服務(wù)器的性能。由于軟硬件平臺日趨多樣性，下列問題將在基于瀏覽器插 件的多媒體應(yīng)用中突顯：1）加大IT公司對于插件和基于該插件的應(yīng)用的研發(fā)和維護(hù)成本；2）加大插件開發(fā)人員對于插件和基于該插件的應(yīng)用的開發(fā)、測試和維 護(hù)工作；3）加大涉及到受版權(quán)保護(hù)的技術(shù)的整合難度；4）加大說服用戶安裝插件的難度。

　　目前，WebRTC由IETF（Internet Engineering Task Force——互聯(lián)網(wǎng)工程任務(wù)組）和W3C（World Wide Web Consortium——萬維網(wǎng)聯(lián)盟）聯(lián)合負(fù)責(zé)其標(biāo)準(zhǔn)化工作。IETF定制WebRTC的互聯(lián)網(wǎng)基礎(chǔ)協(xié)議標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)也被稱為RTCWeb（Real- Time Communication in Web-browsers）。W3C則負(fù)責(zé)定制WebRTC的客戶端JavaScript API接口的標(biāo)準(zhǔn)。目前參與該技術(shù)標(biāo)準(zhǔn)定制的公司主要有思科、微軟、谷歌和愛立信等。其中，微軟為揭示現(xiàn)有WebRTC存在的不足，進(jìn)而推動其不斷向前發(fā) 展，提出了WebRTC的另一種形式，即CU-RTC-Web（Customizable, Ubiquitous Real Time Communication over the Web）。

　　2. 系統(tǒng)構(gòu)成

　　WebRTC是通過將如下功能集成到現(xiàn)有瀏覽器來實(shí)現(xiàn)為異構(gòu)系統(tǒng)提供統(tǒng)一的多媒體實(shí)時通訊平臺：會話管理、音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸。同 時，WebRTC為Web開發(fā)人員提供了Web API （即JavaScript API）來開發(fā)基于Web的音視頻應(yīng)用；為瀏覽器廠商提供了WebRTC Native C++ API用于實(shí)現(xiàn)Web API的函數(shù)集（如圖1所示）。在本章節(jié)，首先，我們介紹WebRTC的組成模塊；其次，我們介紹WebRTC的API接口；最后，我們介紹組成模塊與接 口之間的對應(yīng)關(guān)系。

　　2.1 組成模塊

　　A. 會話管理

　　WebRTC的會話管理也被稱為抽象信令。抽象信令的作用是將具體業(yè)務(wù)與信令控制的分離，從而適應(yīng)廣大Web應(yīng)用中的信令控制。會話管理的實(shí)現(xiàn) 有兩種方式：一種是以瀏覽器為主的實(shí)現(xiàn)方式ROAP（RTCWeb Offer/Answer Protocol），另一種是以Javascript為主的實(shí)現(xiàn)方式JSEP（Javascript Session Establishment Protocol）。前者的優(yōu)點(diǎn)在于可以直接使用現(xiàn)有協(xié)議棧實(shí)現(xiàn)；缺點(diǎn)是靈活度較低，無法支持私有協(xié)議，另外，如果將過多的協(xié)議棧集成到瀏覽器，將使得瀏 覽器會變得“臃腫”。后者的優(yōu)勢在于靈活度高，能夠適用于多種協(xié)議。為提高會話管理的普適性，以及簡化會話管理，W3C通過多次討論，最終采用了 JSEP（JavaScript Session Establishment Protocal）方式來進(jìn)行會話管理。

　　B. 音頻引擎

　　音頻引擎負(fù)責(zé)從麥克到網(wǎng)絡(luò)側(cè)、網(wǎng)絡(luò)側(cè)到音箱的音頻處理。它包含的功能主要有音頻編解碼和聲音處理兩部分。在音頻編解碼上，WebRTC主要采用 兩種語音編碼格式：iSAC（internet Speech Audio Codec）和iLBC（internet Low Bitrate Codec），來分別對寬帶與窄帶環(huán)境的語音進(jìn)行編碼。在聲音處理上，WebRTC主要包括回聲消除、錯誤隱藏和降噪處理等功能，用來降低由網(wǎng)絡(luò)抖動和丟 包等對聲音質(zhì)量造成的影響，并盡可能降低聲音延遲。

　　C. 視頻引擎

　　視頻處理引擎負(fù)責(zé)攝像機(jī)到網(wǎng)絡(luò)側(cè)、網(wǎng)絡(luò)側(cè)到屏幕顯示的視頻處理。它主要包括視頻編解碼和圖像處理。在視頻編解碼上，目前WebRTC主要采用 VP8技術(shù)（未來VP9也將被集成到WebRTC中），使得WebRTC在較低碼率的環(huán)境，提供較高質(zhì)量的視頻。在圖像處理上，WebRTC主要包括抖動 緩沖和圖像增強(qiáng)等功能，用來降低從攝像機(jī)采集到的圖像的噪音。

　　D. 網(wǎng)絡(luò)傳輸

　　網(wǎng)絡(luò)傳輸負(fù)責(zé)對采集到的音視頻數(shù)據(jù)進(jìn)行加密、防火墻穿透和傳輸。WebRTC將設(shè)備采集到的音視頻數(shù)據(jù)在加密的情況下采用SRTP協(xié)議進(jìn)行傳 輸，以確保信息在傳輸過程中的安全性。另外，WebRTC采用STUN、TURN和ICE等協(xié)議棧對VoIP網(wǎng)絡(luò)中的防火墻或者NAT進(jìn)行穿透。其 中，STUN可以處理大部分NAT穿透問題；TURN是STUN協(xié)議的一個增強(qiáng)版，專門用于處理對稱形NAT穿透問題；ICE是一個整合了STUN和 TURN的框架，為VoIP或視頻通話配置以及媒體傳輸提供可靠的服務(wù)。

　　圖 1 WebRTC總體架構(gòu)，摘自百度百科

　　2.2 封裝API

　　WebRTC將音視頻數(shù)據(jù)從設(shè)備采集到網(wǎng)絡(luò)傳輸過程中涉及的功能封裝到以下3個主要API：MediaStream、 PeerConnection和DataChanel。MediaStream（即getUserMedia）用于表示被獲取的媒體數(shù)據(jù)，例如來自麥克風(fēng) 和攝像頭音視頻流。PeerConnection用于表示在兩個瀏覽器之間的連接。DataChannel表示一個在兩個節(jié)點(diǎn)之間的雙向的數(shù)據(jù)通道。值得 注意的是由于WebRTC的標(biāo)準(zhǔn)化工作還未完成，所以目前這幾個API的名稱在不同瀏覽器及同一瀏覽器的不同版本之間略有差異，比如 PeerConnection在FireFox上叫做mozRTCPeerConnection，而在當(dāng)前版本的Chrome上叫做 webkitRTCPeerConnection。
 

　　2.3 模塊與API之間的關(guān)系

　　在這節(jié)，我們將通過WebRTC的工作原理來闡述WebRTC各個組成模塊與所封裝的JavaScript API之間的關(guān)聯(lián)關(guān)系。圖2是一個WebRTC的工作原理示意圖。在圖2中，有兩個集成WebRTC的瀏覽器，一個信令服務(wù)器，一個STUN/TURN服 務(wù)器。瀏覽器訪問基于WebRTC的Web應(yīng)用。信令服務(wù)器對Web應(yīng)用的信令進(jìn)行解析。STUN/TURN服務(wù)器對Web應(yīng)用進(jìn)行NAT或防火墻穿透， 以建立兩個客戶端的通信連接。具體工作流程如下：首先，使用Web應(yīng)用的雙方通過PeerConnection API將呼叫和應(yīng)答請求發(fā)送給信令服務(wù)器；然后，STUN/TURN服務(wù)器對呼叫雙方的防火墻和NAT進(jìn)行穿透；之后，MediaStream通過音視頻 引擎對音視頻數(shù)據(jù)進(jìn)行采集；最后，Web應(yīng)用將采集到的音視頻數(shù)據(jù)發(fā)送到DataChanel，并采用RTP/SRTP協(xié)議進(jìn)行傳輸。

　　圖 2 WebRTC各個組成模塊與所封裝的JavaScript API之間的關(guān)聯(lián)關(guān)系

　　2.4 應(yīng)用場景

　　WebRTC的音視頻應(yīng)用從連接的客戶端的數(shù)量角度來區(qū)分，可以分為一對一模式和多人模式。同時，WebRTC為了取得快速的發(fā)展，其勢必對傳統(tǒng)網(wǎng)絡(luò)，例如SIP，XMPP和PSTN網(wǎng)絡(luò)進(jìn)行無縫對接。

　　A. 一對一模式

　　該模式是最簡單的應(yīng)用模式。在上文圖2中闡述WebRTC模塊與API之間關(guān)聯(lián)關(guān)系時的例子就是一個一對一模式。該模式的工作原理描述如下。首 先，基于WebRTC的Web應(yīng)用通過Web服務(wù)器來進(jìn)行信令解析。然后，每個瀏覽器將本地采集到的音視頻數(shù)據(jù)發(fā)送給對端瀏覽器。最后，每個瀏覽器對本地 和對端的多媒體數(shù)據(jù)進(jìn)行處理和顯示。

　　圖 3 一對一模式

　　B. 多人模式

　　相比較于一對一模式，多人模式則更加復(fù)雜。該模式與一對一模式不同的是，每個瀏覽器將本地采集到的音視頻數(shù)據(jù)廣播給其余所有瀏覽器（如圖 4（a）所示）。由于終端的處理能力，電池續(xù)航能力以及網(wǎng)絡(luò)帶寬的限制，WebRTC目前最多能夠支持6個人同時進(jìn)行音視頻服務(wù)。為擺脫由于終端的有限能 力對WebRTC多人模式中人數(shù)的限制，目前，有些公司（例如因特爾）為WebRTC的特定應(yīng)用提供MCU媒體控制單元。MCU負(fù)責(zé)對不同格式的音視頻進(jìn) 行轉(zhuǎn)碼和將多人模式中的音視頻流整合在一起再廣播給每一個終端?；贛CU的多人模式的工作流程，如圖4（b）所示。

 

 

　　（a） （b）

　　圖 4（a）WebRTC原生多人通信模式，（b）基于MCU的多人通信模式。

　　C. WebRTC與現(xiàn)有網(wǎng)絡(luò)的互通模式

　　由于在WebRTC出現(xiàn)之前，實(shí)時通訊業(yè)務(wù)已經(jīng)取得了很大的發(fā)展。因此，WebRTC應(yīng)與現(xiàn)有的實(shí)時通信業(yè)務(wù)無縫對接，才能取得快速的發(fā)展。為 了與傳統(tǒng)實(shí)時通信業(yè)務(wù)進(jìn)行無縫對接，目前，各個廠商根據(jù)WebRTC和現(xiàn)有的實(shí)時通信業(yè)務(wù)開發(fā)出相應(yīng)的網(wǎng)關(guān)設(shè)備，比如對應(yīng)SIP/XMPP的服務(wù)器和 PSTN（Public Switched Telephone Network——公共交換電話網(wǎng)絡(luò)）網(wǎng)關(guān)。該網(wǎng)關(guān)負(fù)責(zé)將通過瀏覽器訪問的Web應(yīng)用和傳統(tǒng)客戶端訪問的現(xiàn)有實(shí)時通信應(yīng)用的信令進(jìn)行適配，甚至多媒體格式 之間的轉(zhuǎn)化。具體的業(yè)務(wù)邏輯如圖5所示。

　　圖 5 WebRTC與現(xiàn)有網(wǎng)絡(luò)的互通模式

　　3. WebRTC的發(fā)展與影響

　　3.1 發(fā)展

　　首先，Android系統(tǒng)內(nèi)置的瀏覽器和個人電腦中主流的Web瀏覽器（例如Chrome，F(xiàn)irefox和Opera）已經(jīng)支持 WebRTC。根據(jù)Dialogic公布的2013年“WebRTC影響調(diào)查”報告，在2013年，Android在移動智能終端的市場占有率是 69%；Chrome，F(xiàn)irefox和Opera三大主流Web瀏覽器在個人電腦的市場占有率是39%。另外，其他Web瀏覽器（比 如，Maxthon）也將支持WebRTC。因此，WebRTC將被快速的部署在日常設(shè)備（即移動智能終端和個人電腦等）。其次，由于WebRTC的本質(zhì) 是一項基于Web瀏覽器的實(shí)時通信技術(shù)，它將最先應(yīng)用在IM（Instant Messenger——即時通信）領(lǐng)域。由于IM應(yīng)用通常應(yīng)用在社交網(wǎng)絡(luò)，這使得WebRTC可以依靠社交網(wǎng)絡(luò)所具有的小世界網(wǎng)絡(luò)特性（即雖然這種網(wǎng)絡(luò)中 大部份的節(jié)點(diǎn)彼此并不相連，但絕大部份節(jié)點(diǎn)之間經(jīng)過少數(shù)幾步就可到達(dá)——摘自維基百科）快速的被用戶所使用?；谝陨蟽牲c(diǎn)，WebRTC技術(shù)的部署和使用 將呈現(xiàn)爆炸式的增長。
　3.2  影響

　　WebRTC技術(shù)的快速普及將對現(xiàn)有的很多領(lǐng)域產(chǎn)生巨大的影響。 首先，受到影響的是現(xiàn)有的VoIP業(yè)務(wù)領(lǐng)域。目前我們正在經(jīng)歷一個硬件多樣化的時代，比如可穿戴設(shè)備的興起。這將促進(jìn)適應(yīng)新型設(shè)備的操作系統(tǒng)的涌現(xiàn)和加大 現(xiàn)有操作系統(tǒng)的分化。因此，操作系統(tǒng)的異構(gòu)性和繁雜性使得VoIP應(yīng)用的開發(fā)、更新與維護(hù)的復(fù)雜性和成本劇增。隨著WebRTC集成到瀏覽器中，基于 Web的實(shí)時通信應(yīng)用可以通過HTML標(biāo)簽和JavaScript API實(shí)現(xiàn)快速的開發(fā)，并避免了由于操作系統(tǒng)的異構(gòu)性帶來的重復(fù)開發(fā)和由于版本升級帶來的維護(hù)費(fèi)用以及不便。這將導(dǎo)致現(xiàn)有的應(yīng)用開發(fā)人員從現(xiàn)有的基于瀏覽 器插件或者原生VoIP應(yīng)用模式轉(zhuǎn)向使用WebRTC進(jìn)行Web應(yīng)用開發(fā)，進(jìn)而使得現(xiàn)有的VoIP應(yīng)用的普通用戶向基于瀏覽器的Web應(yīng)用的遷移。目前， 涉及VoIP業(yè)務(wù)的客服以及在線教育領(lǐng)域很關(guān)注WebRTC技術(shù)在自身領(lǐng)域的應(yīng)用。

　　其次，現(xiàn)有的IM應(yīng)用通過其擁有的大量用戶，并通過構(gòu)建在這些IM應(yīng)用上的衍生應(yīng)用形成生態(tài)圈。這些IM應(yīng)用及其所形成的生態(tài)圈正在試圖取代瀏 覽器成為互聯(lián)網(wǎng)入口。這種現(xiàn)象在移動智能終端表現(xiàn)的更加突出。然而，如上文所述，WebRTC技術(shù)的部署和使用將呈現(xiàn)爆炸式的增長，這將導(dǎo)致IM應(yīng)用向 IM Web應(yīng)用的轉(zhuǎn)變和用戶向IM Web應(yīng)用的遷移。因此，構(gòu)建在現(xiàn)有IM應(yīng)用的生態(tài)圈將被打破?，F(xiàn)有的IM應(yīng)用及其生態(tài)圈必將做出相應(yīng)的布局調(diào)整以適應(yīng)新的技術(shù)環(huán)境。

　　同時，WebRTC的普及將給企業(yè)帶來監(jiān)管和安全問題。目前，有些公司在公司內(nèi)部封鎖了IM應(yīng)用（比如QQ，Skype）的端口，以防止員工在 工作過程中由于對音視頻工具的不慎使用所造成的安全問題?；赪ebRTC的新型IM Web應(yīng)用，與正常的Web頁面無異，所以很難檢測該種IM Web應(yīng)用。這給企業(yè)的監(jiān)管和安全造成了巨大的隱患。

　　其次，智能電視的展現(xiàn)形式和業(yè)務(wù)模式將受到巨大的影響。目前，智能電視主要包括智能操作系統(tǒng)以及顯示設(shè)備。在智能電視上的主要業(yè)務(wù)也主要是對多 媒體源的直播和點(diǎn)播。隨著WebRTC的普及和涌現(xiàn)大量的IM Web應(yīng)用，智能電視將很可能原生的包含攝像頭設(shè)備。同時，視頻會議業(yè)務(wù)也將像現(xiàn)在的對多媒體源的直播和點(diǎn)播業(yè)務(wù)一樣，成為智能電視的主要業(yè)務(wù)。

　　其次，所上文所述，由于WebRTC所支持的音視頻格式的局限，以及WebRTC在多人視頻會話中采用的可選網(wǎng)狀結(jié)構(gòu)的限制（目前是6人）。新 型的服務(wù)供應(yīng)商將產(chǎn)生。這些供應(yīng)商主要提供1）不同視頻編解碼的轉(zhuǎn)換；2）在多人會話中，視頻流的整合與廣播。目前，服務(wù)供應(yīng)商及其產(chǎn)品 有：Dialogic推出的PowerMedia XMS 2.1和英特爾推出的Collaboration Service for WebRTC。

　　最后，集成了WebRTC的Web瀏覽器將進(jìn)一步改變傳統(tǒng)的應(yīng)用、Web瀏覽器和操作系統(tǒng)的格局。Web瀏覽器將成為介于操作系統(tǒng)與Web應(yīng)用 的一個平臺。為Web操作系統(tǒng)的普及進(jìn)一步鋪平道路。包含了WebRTC的瀏覽器將進(jìn)一步鞏固其互聯(lián)網(wǎng)入口的地位——近些年，超級應(yīng)用（例如微信）通過其 擁有的大量用戶和在其上的開發(fā)的衍生應(yīng)用試圖成為互聯(lián)網(wǎng)入口。Web瀏覽器及其Web應(yīng)用將成為一種生態(tài)圈。高性能瀏覽器的研發(fā)將成為下一個競爭熱點(diǎn)。而 瀏覽器的安全問題將更加凸顯。

　　4. 總結(jié)

　　在本文中，我們首先介紹了WebRTC技術(shù)產(chǎn)生的意義。其次，我們展示了WebRTC技術(shù)架構(gòu)中各個組成模塊和所封裝的JavaScript API，以及模塊與JavaScript API之間的對應(yīng)關(guān)系；同時，我們也闡述了WebRTC的工作模式以及與現(xiàn)有多媒體網(wǎng)絡(luò)的對接模式。之后，我們根據(jù)WebRTC的載體（即Web瀏覽器） 在移動終端和個人PC中的占有率以及這些載體對WebRTC的支持程度做出了WebRTC技術(shù)的部署和使用將呈現(xiàn)爆炸式的增長的判斷。最后，我們闡述了 WebRTC對現(xiàn)有實(shí)時通訊行業(yè)和智能電視行業(yè)的影響，并闡述由于WebRTC的引入將進(jìn)一步改變應(yīng)用、Web瀏覽器和操作系統(tǒng)三者的格局