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