1. 前言
WebRTC（Web Real-Time Communication——網(wǎng)頁(yè)實(shí)時(shí)通信）是一個(gè)基于瀏覽器的實(shí)時(shí)多媒體通信技術(shù)。該項(xiàng)技術(shù)旨在使Web瀏覽器具備實(shí)時(shí)通信能力；同時(shí)，通過(guò)將這些能力封裝并以JavaScript API的方式開(kāi)放給Web應(yīng)用開(kāi)發(fā)人員，使得Web應(yīng)用開(kāi)發(fā)人員能夠通過(guò)HTML標(biāo)簽和JavaScript API快速地開(kāi)發(fā)出基于Web瀏覽器的實(shí)時(shí)音視頻應(yīng)用，而無(wú)需依賴(lài)任何第三方插件。該項(xiàng)技術(shù)將Web瀏覽器打造成一個(gè)適用于在所有用戶(hù)設(shè)備（比如移動(dòng)智能終端和個(gè)人電腦等）間進(jìn)行實(shí)時(shí)的音視頻和數(shù)據(jù)通信的通用平臺(tái)。
在WebRTC技術(shù)出現(xiàn)之前，基于Web瀏覽器的多媒體通信服務(wù)是構(gòu)建在特定的瀏覽器插件（如Adobe Flash Player）之上的，因?yàn)闉g覽器所依賴(lài)的HTTP協(xié)議是一種無(wú)連接狀態(tài)的協(xié)議——即瀏覽器與服務(wù)器建立連接，下載文件，斷開(kāi)連接，再顯示接收到的文件。因此，瀏覽器不能與服務(wù)器實(shí)時(shí)動(dòng)態(tài)地交換數(shù)據(jù)。無(wú)連接狀態(tài)的HTTP協(xié)議導(dǎo)致需要實(shí)時(shí)通信的服務(wù)（如聊天等）只能采取定時(shí)訪(fǎng)問(wèn)服務(wù)器的方法（即輪詢(xún)方式）來(lái)實(shí)現(xiàn)。然而，在用戶(hù)訪(fǎng)問(wèn)量增多時(shí)，這種方式嚴(yán)重的消耗服務(wù)器端資源，進(jìn)而嚴(yán)重的影響服務(wù)器的性能。由于軟硬件平臺(tái)日趨多樣性，下列問(wèn)題將在基于瀏覽器插件的多媒體應(yīng)用中突顯：1）加大IT公司對(duì)于插件和基于該插件的應(yīng)用的研發(fā)和維護(hù)成本；2）加大插件開(kāi)發(fā)人員對(duì)于插件和基于該插件的應(yīng)用的開(kāi)發(fā)、測(cè)試和維護(hù)工作；3）加大涉及到受版權(quán)保護(hù)的技術(shù)的整合難度；4）加大說(shuō)服用戶(hù)安裝插件的難度。
目前，WebRTC由IETF（Internet Engineering Task Force——互聯(lián)網(wǎng)工程任務(wù)組）和W3C（World Wide Web Consortium——萬(wàn)維網(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)也被稱(chēng)為RTCWeb（Real-Time Communication in Web-browsers）。W3C則負(fù)責(zé)定制WebRTC的客戶(hù)端JavaScript API接口的標(biāo)準(zhǔn)。目前參與該技術(shù)標(biāo)準(zhǔn)定制的公司主要有思科、微軟、谷歌和愛(ài)立信等。其中，微軟為揭示現(xiàn)有WebRTC存在的不足，進(jìn)而推動(dòng)其不斷向前發(fā)展，提出了WebRTC的另一種形式，即CU-RTC-Web（Customizable, Ubiquitous Real Time Communication over the Web）。
2. 系統(tǒng)構(gòu)成
WebRTC是通過(guò)將如下功能集成到現(xiàn)有瀏覽器來(lái)實(shí)現(xiàn)為異構(gòu)系統(tǒng)提供統(tǒng)一的多媒體實(shí)時(shí)通訊平臺(tái)：會(huì)話(huà)管理、音頻引擎、視頻引擎和網(wǎng)絡(luò)傳輸。同時(shí)，WebRTC為Web開(kāi)發(fā)人員提供了Web API （即JavaScript API）來(lái)開(kāi)發(fā)基于Web的音視頻應(yīng)用；為瀏覽器廠商提供了WebRTC Native C++ API用于實(shí)現(xiàn)Web API的函數(shù)集（如圖1所示）。在本章節(jié)，首先，我們介紹WebRTC的組成模塊；其次，我們介紹WebRTC的API接口；最后，我們介紹組成模塊與接口之間的對(duì)應(yīng)關(guān)系。
2.1 組成模塊
A. 會(huì)話(huà)管理
WebRTC的會(huì)話(huà)管理也被稱(chēng)為抽象信令。抽象信令的作用是將具體業(yè)務(wù)與信令控制的分離，從而適應(yīng)廣大Web應(yīng)用中的信令控制。會(huì)話(huà)管理的實(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)是靈活度較低，無(wú)法支持私有協(xié)議，另外，如果將過(guò)多的協(xié)議棧集成到瀏覽器，將使得瀏覽器會(huì)變得“臃腫”。后者的優(yōu)勢(shì)在于靈活度高，能夠適用于多種協(xié)議。為提高會(huì)話(huà)管理的普適性，以及簡(jiǎn)化會(huì)話(huà)管理，W3C通過(guò)多次討論，最終采用了JSEP（JavaScript Session Establishment Protocal）方式來(lái)進(jìn)行會(huì)話(huà)管理。
B. 音頻引擎
音頻引擎負(fù)責(zé)從麥克到網(wǎng)絡(luò)側(cè)、網(wǎng)絡(luò)側(cè)到音箱的音頻處理。它包含的功能主要有音頻編解碼和聲音處理兩部分。在音頻編解碼上，WebRTC主要采用兩種語(yǔ)音編碼格式：iSAC（internet Speech Audio Codec）和iLBC（internet Low Bitrate Codec），來(lái)分別對(duì)寬帶與窄帶環(huán)境的語(yǔ)音進(jìn)行編碼。在聲音處理上，WebRTC主要包括回聲消除、錯(cuò)誤隱藏和降噪處理等功能，用來(lái)降低由網(wǎng)絡(luò)抖動(dòng)和丟包等對(duì)聲音質(zhì)量造成的影響，并盡可能降低聲音延遲。
C. 視頻引擎
視頻處理引擎負(fù)責(zé)攝像機(jī)到網(wǎng)絡(luò)側(cè)、網(wǎng)絡(luò)側(cè)到屏幕顯示的視頻處理。它主要包括視頻編解碼和圖像處理。在視頻編解碼上，目前WebRTC主要采用VP8技術(shù)（未來(lái)VP9也將被集成到WebRTC中），使得WebRTC在較低碼率的環(huán)境，提供較高質(zhì)量的視頻。在圖像處理上，WebRTC主要包括抖動(dòng)緩沖和圖像增強(qiáng)等功能，用來(lái)降低從攝像機(jī)采集到的圖像的噪音。
D. 網(wǎng)絡(luò)傳輸
網(wǎng)絡(luò)傳輸負(fù)責(zé)對(duì)采集到的音視頻數(shù)據(jù)進(jìn)行加密、防火墻穿透和傳輸。WebRTC將設(shè)備采集到的音視頻數(shù)據(jù)在加密的情況下采用SRTP協(xié)議進(jìn)行傳輸，以確保信息在傳輸過(guò)程中的安全性。另外，WebRTC采用STUN、TURN和ICE等協(xié)議棧對(duì)VoIP網(wǎng)絡(luò)中的防火墻或者NAT進(jìn)行穿透。其中，STUN可以處理大部分NAT穿透問(wèn)題；TURN是STUN協(xié)議的一個(gè)增強(qiáng)版，專(zhuān)門(mén)用于處理對(duì)稱(chēng)形NAT穿透問(wèn)題；ICE是一個(gè)整合了STUN和TURN的框架，為VoIP或視頻通話(huà)配置以及媒體傳輸提供可靠的服務(wù)。
圖 1 WebRTC總體架構(gòu)，摘自百度百科
