Web的實時通信技術(shù)或簡稱WebRTC（Web Real Time Communication）是最近由Google推出的一項旨在支持網(wǎng)絡(luò)瀏覽器進行實時語音對話或視頻對話的軟件架構(gòu)。和傳統(tǒng)的基于本地客戶端或瀏覽器插件的多媒體通信方式不同，WebRTC通過將多媒體通信所必須的音視頻處理（采集、編碼、增強）、網(wǎng)絡(luò)傳輸、會話控制等核心模塊集成到瀏覽器內(nèi)部，從而使第三方應(yīng)用開發(fā)者僅需通過簡單的JavaScript API調(diào)用即可獲得實時的音視頻通信能力。
對于傳統(tǒng)電信運營商而言，WebRTC技術(shù)既帶來挑戰(zhàn)，也意味著機遇。一方面，憑借瀏覽器的高市場占有率和龐大的用戶量，WebRTC技術(shù)能夠在很大程度上改變現(xiàn)有實時多媒體通信業(yè)務(wù)的生態(tài)環(huán)境和游戲規(guī)則，對運營商現(xiàn)有的以及未來將要在IMS網(wǎng)絡(luò)中力推的多媒體實時通信業(yè)務(wù)產(chǎn)生沖擊。另一方面，如果能夠?qū)崿F(xiàn)WebRTC技術(shù)與IMS的強強聯(lián)合，也可以利用WebRTC作為WebApp所天生具有的規(guī)模推廣、快速部署、維護成本低等優(yōu)勢，將其轉(zhuǎn)化為推進IMS業(yè)務(wù)開展的重要動力，為IMS用戶提供更加豐富的新應(yīng)用，促使傳統(tǒng)用戶向IMS網(wǎng)絡(luò)遷移，從而有效地將IMS能力轉(zhuǎn)化為企業(yè)的商業(yè)價值。因此，WebRTC技術(shù)的的發(fā)展也受到運營商、愛立信、思科等設(shè)備制造廠商的關(guān)注。
WebRTC架構(gòu)已獲多方支持
WebRTC軟件架構(gòu)由兩套應(yīng)用程序調(diào)用接口組成：Web API與Native API。
Web API是WebRTC項目提供給第三方多媒體通信應(yīng)用開發(fā)者的一套JavaScript實現(xiàn)的API。為了令WebRTC應(yīng)用能夠“一次開發(fā)，隨處運行”，互聯(lián)網(wǎng)標準化組織W3C已經(jīng)開展了 WebRTC 1.0草案的制定工作，提供一些重要的API接口如Network Stream API與getUserMedia API。Native API是一組根據(jù)Web API定義的底層C++接口，二次開發(fā)者可以利用JavaScript對其進行封裝供給瀏覽器調(diào)用，或者直接用其開發(fā)本地程序。因為Native API需要直接與底層的硬件及操作系統(tǒng)進行交互，所以在不同的系統(tǒng)環(huán)境，如Windows、Linux、Android中不盡相同。不同瀏覽器如Chrome、Firefox、Opera等，也會有不同的實現(xiàn)方式。
從具體實現(xiàn)來看，WebRTC向瀏覽器加入了視頻引擎、音頻引擎、網(wǎng)絡(luò)傳輸及會話控制等新功能模塊。其中，音視頻引擎模塊提供了從音視頻采集設(shè)備，如麥克風(fēng)、攝像頭，到網(wǎng)絡(luò)側(cè)音視頻處理鏈的總體框架。為了避免專利糾紛，音視頻編碼都采用了開源的編碼格式，如iLBC、iSAC、VP8等，同時提供相應(yīng)的抖動緩沖及音視頻增強等功能。在網(wǎng)絡(luò)傳輸方面，WebRTC使用RTP/SPRT進行媒體流傳輸，使用ICE（Interactive Connectivity Establishment）技術(shù)進行媒體流的私網(wǎng)穿透。WebRTC客戶端使用JSEP（Javascript Session Establishment Protocol）協(xié)議草案規(guī)范WebRTC通信雙方應(yīng)如何交換SDP信息，并進行媒體流協(xié)商和控制。JSEP的設(shè)計思路將媒體層的控制交由瀏覽器，而將信令層的控制交由Web應(yīng)用開發(fā)者，從而使得信令狀態(tài)機可與瀏覽器徹底分離，保持了協(xié)議的靈活性。目前，這些功能已經(jīng)被集成到Google的Chrome瀏覽器中，其他瀏覽器如FireFox、Opera、IE10等也都宣稱已經(jīng)或?qū)С諻ebRTC的主要功能。
WebRTC在IMS網(wǎng)絡(luò)中的部署
以下介紹一種如何在基于SIP的IMS網(wǎng)絡(luò)架構(gòu)中部署WebRTC端到端實時音視頻通信應(yīng)用的組網(wǎng)方案。出于復(fù)雜性的考慮，僅考慮了同類WebRTC客戶端間的互通，而不涉及與其他SIP終端或PSTN電話間的互通問題。如圖所示，WebRTC客戶端是以JavaScript編寫的，運行于Web瀏覽器中的Web應(yīng)用，直接或通過私有網(wǎng)關(guān)連接至Internet網(wǎng)絡(luò)。業(yè)務(wù)平臺需要架設(shè)WebRTC代理服務(wù)器和STUN（Session Traversal Utilities for NAT）+TURN（Traversal Using Relays around NAT）服務(wù)器。SIP服務(wù)器則基于IMS核心網(wǎng)的原有配置，不做任何改動。圖中的WebRTC客戶端皆位于NAT或防火墻之后。在通信過程中，信令流與媒體流分兩路進行傳輸。
1）WebRTC客戶端
WebRTC客戶端是運行在瀏覽器中的Web應(yīng)用程序，采用JavaScript腳本語言編寫。其核心部分是一個SIP協(xié)議棧，用于發(fā)送、接收、解析SIP信令，以及維護SIP信令狀態(tài)機。本方案中，WebRTC客戶端作為WebSocket客戶端通過WebSocket接口與WebSocket代理服務(wù)器相互連接。WebRTC客戶端將SIP消息作為凈載荷封裝在WebSocket消息中進行傳送。
2）WebSocket代理服務(wù)器
WebSocket協(xié)議屬于HTML5標準的一部分，是一種以HTML協(xié)議為傳輸層，用于實現(xiàn)瀏覽器間雙向通信的協(xié)議。WebSocket協(xié)議兼容于現(xiàn)有HTTP 1.1協(xié)議，并通過Upgrade: websocket將協(xié)議升級為WebSocket協(xié)議。這樣做可以充分利用HTTP協(xié)議現(xiàn)有的代理、過濾、認證等機制，從而大大降低了協(xié)議棧的開發(fā)成本。如圖所示，通信雙方通過WebSocket連接至WebSocket代理服務(wù)器。由于WebSocket連接是基于TCP的，因此不存在私網(wǎng)穿透問題。WebSocket代理服務(wù)器開啟偵聽端口，等待WebRTC客戶端發(fā)起連接。當連接建立后，WebSocket代理服務(wù)器接收WebRTC客戶端所發(fā)送的經(jīng)過WebSocket封裝的SIP消息，抽取出SIP消息后將SIP消息以UDP包形式發(fā)送給SIP服務(wù)器。SIP服務(wù)器將應(yīng)答以UDP包形式返回給WebSocket代理服務(wù)器，WebSocket代理服務(wù)器會將SIP消息目的地址替換成實際的目的地址，再重新以WebSocket進行封裝，然后發(fā)給消息接收方，從而實現(xiàn)客戶端之間以及客戶端與服務(wù)器端間的通信。
3）STUN+TURN服務(wù)器
WebRTC的媒體流采用ICE技術(shù)進行私網(wǎng)穿透，此功能需要STUN或TURN服務(wù)器進行支持。圖中給出的是使用TURN的情形，即兩個WebRTC客戶端皆位于對稱NAT之后。此時媒體流必須通過TURN服務(wù)器進行中繼才能夠到達對方。
4）SIP服務(wù)器
這里將IMS核心網(wǎng)簡單抽象成為一臺SIP服務(wù)器，實際上其是由CSCF、HSS等多個網(wǎng)元構(gòu)成，并通過BAC網(wǎng)元與WebSocket服務(wù)器相連接。SIP服務(wù)器的主要功能是進行用戶認證以及通話過程控制，但不負責(zé)媒體流的傳輸。通話雙方必須事先在SIP服務(wù)器上注冊，并周期性發(fā)送心跳包保持在線狀態(tài)。
目前，WebRTC仍處于其技術(shù)演進的早期階段，相關(guān)標準文稿也在不斷修訂，在IMS網(wǎng)絡(luò)中部署基于WebRTC的音視頻實時通信應(yīng)用的方式也存在許多不完善之處，如沒有考慮視頻會議等多方通話場景，沒有考慮與現(xiàn)有SIP終端、PSTN電話，以及其他類型的WebRTC終端間的互通問題等。但相信隨著相關(guān)標準和技術(shù)的不斷完善，將WebRTC技術(shù)與IMS的結(jié)合將煥發(fā)更強大的生命，傳統(tǒng)電信運營商如果能夠把握未來互聯(lián)網(wǎng)技術(shù)的發(fā)展方向，妥善利用WebRTC這一重要機遇，對于推進IMS業(yè)務(wù)開展、開拓新的業(yè)務(wù)領(lǐng)域?qū)⑵鸬绞址e極作用。
京公網(wǎng)安備 11010502049343號