RTCWeb及其與IMS的融合研究

樂利鋒，彭 晉，段曉東

（中國移動通信研究院 北京 100053）

1 引言

Web應用已成為互聯網應用最成功的模式之一，其應用范疇已經滲透人類社會生活的各個領域。人們只要通過一款瀏覽器，就可以享受到無窮無盡的Web服務，如各種電子商務、網絡游戲、社區服務及各種網絡交友等。與此同時，Web技術所帶來的優勢（如統一的客戶端和較好的可維護性），使一些傳統應用紛紛轉型到Web模式。Web應用開發的簡單快速也受到開發者青睞，開發者只需要一次開發就可以在任何地方部署，代碼片段很容易在開發者之間被復制和粘貼，越來越容易掌握的JavaScript庫使開發更加快捷。

Web瀏覽器一直隨著Web應用的需要持續加入新的Web 特性，W3C（world wide web consortium，萬維網聯盟）標準化組織追求的Open Web Platform[1]是所有Web技術的集合，不僅包括基礎 Web技術，如 HTML（hypertext markup language，超文本標記語言）、CSS（cascading style sheet，級聯樣式表）和 JavaScript及 HTTP（hypertext transfer protocol，超文本傳輸協議）等；還包括新的Web技術，如HTML5[2]，允許開發者免費使用它所發布的技術?？梢灶A見，未來Web將逐漸成為一種準入門檻較低、推廣成本可控的統一應用平臺。

基于Web的實時通信應用可以吸引越來越多的用戶。Facebook[3]推出了整合Skype的視頻聊天服務，首次使用該功能的用戶需要安裝插件；GoogleTalk[4]網頁版的正常使用需要安裝Google話音和視頻聊天插件，在瀏覽器中成功安裝插件后，可以直接在Gmail[5]或iGoogle[6]中進行視頻和話音通話。但這些插件對于不同瀏覽器需要不同的開發實現，且需要用戶安裝，具有一定的安全隱患。為了避免引入新插件，一些 Web 網絡電話（如 Alicall[7]、FlashVoIP[8]）采用普及程度比較高的flash player插件實現實時通信功能，可重用flash插件自有RTMP（real time messaging protocol，實時消息傳送協議）[9]信令和媒體傳輸協議。但flash插件方式需要依托第三軟件提供商的支持，大規模商用更需要支付相當可觀的費用。

如果徹底不引入插件，Web實時通信客戶端在執行效率方面想接近傳統客戶端或插件客戶端的效果，需要瀏覽器提供更多新特性的支持。為了實現實時通信功能，瀏覽器至少需要具備會話管理、音視頻編解碼引擎和媒體傳輸等功能。會話管理功能允許開發者為上層應用實現呼叫建立和管理；音視頻編解碼引擎功能允許外設（如麥克風及攝像頭）將采集的數據進行編碼并發送給網絡，或者將接收的媒體進行解碼供外設（如音箱或者顯示器）呈現；媒體傳輸功能實現對不同網絡的NAT（network address translation，網絡地址轉換）或防火墻穿越，并實現對媒體內容的封裝傳輸。

對于無插件Web實時通信應用開發，開發者需要調用瀏覽器API（application programming interface,應用程序編程接口）才能使用其實時通信模塊功能。如果缺少對實時通信模塊API的統一使用規范，不同瀏覽器廠商對API的定義和使用可能出現很大的差異，開發者需要了解不同版本的API使用方法，從而可能會影響開發周期。所以，業界希望Web瀏覽器的實時通信能力被標準化的呼聲越來越高。IETF（internet engineering task force，工程任務組）和W3C這兩大標準化組織從2011年開始積極推進基于Web瀏覽器的實時通信 （real-time communication in web-browsers，RTCWeb）標準化工作[10,11]，力圖提出一個能夠在Web瀏覽器上實現用戶之間話音和視頻等實時通信的標準化框架。IETF的主要工作在于標準化基于瀏覽器的實時通信的架構和協議；W3C的主要工作在于標準化瀏覽器與Web應用之間的API，即上層Web應用通過JavaScrip編程調用這些被標準化的API，實現對瀏覽器RTCWeb功能的使用，如捕獲本地設備的媒體內容、呈現媒體內容、建立點對點媒體通信等。隨著RTCWeb標準化的逐漸深入和影響力的逐步增強，各大瀏覽器廠商如 Chrome、Mozilla Firefox、Safari和Opera紛紛宣布支持或部分支持RTCWeb功能，RTCWeb瀏覽器逐漸步入舞臺并占據相當的市場份額。

2 RTCWeb關鍵技術

2.1 RTCWeb通信模型

IETF RTCWeb工作組建議的典型架構[12]如圖1所示。Web客戶端是基于瀏覽器的融合JavaScript、HTML及CSS的技術客戶端實現，對瀏覽器和Web服務器的會話信令面操作是通過JSEP控制實現的；通過JavaScript調用RTCWeb API，實現對瀏覽器能力的使用；Web客戶端通過JavaScript與Web服務器傳遞基于Web Socket承載的RTCWeb信令消息。RTCWeb信令協議由Web應用定義，可以是標準的協議，如 SIP（session initiation protocol，會話初 始 協 議 ）、XMPP （extensible messaging and presence protocol，可擴展消息處理現場協議）或私有協議，但媒體協商可參考基于Offer/Answer模型的ROAP（RTCWeb offer/answer protocol）；Web服務器之間采用雙方認同的協議，如 SIP或者 XMPP；瀏覽器之間采用RTP（real-time transport protocol，實時傳輸協議）或 SRTP（secure RTP，安全實時傳輸協議）用于媒體傳輸，同時采用ICE（interactive connectivity establishment，交互式連接建立）協議用于防火墻穿越。

圖1 RTCWeb通信模型

2.2 RTCWeb瀏覽器API

W3C WebRTC工作組的關注重點在于瀏覽器端API的標準化[13]，通過調用標準化API實現從本地設備（如攝像頭、麥克風或網絡攝像機）捕獲并呈現本地音視頻媒體內容、通過NAT穿越技術建立點對點連接、基于點對點連接交換媒體內容。這些功能的實現主要由Stream API和Peer Connection兩大類API實現。

Stream抽象了對實際媒體流表示及操作的方法和屬性，目前定義了若干重要的接口，主要是Media Stream。Media Stream對象可以表示從遠端節點或者發送給遠端節點的媒體流；從網絡傳輸Media Stream角度看，每個Media Stream對象都有一個輸入和輸出，來自遠端節點的Media Stream（由Peer Connection實例化產生）可以看作輸入；本地設備產生的Media Stream（調用getUserMedia函數產生）傳給遠端節點便有一個輸出；對于媒體流的呈現，需要專用URL來表示一個媒體流并在網頁中表現出來 （調用createObjectURL函數生成）。

Peer Connection抽象了瀏覽器之間信令交互及媒體通道建立的方法和屬性，通過開通媒體通道，Media Stream對象表示的媒體流可被送到對端。一個Peer Connection對象實現3類功能，即ICE代理 （利用ICE方式實現NAT穿越，如依賴STUN或者TURN服務器）、Peer Connection狀態（標識當前連接狀態，如“new”、“opening”、“active”等）和ICE 狀態（標識穿越狀態，如“new”“waiting”“connected”等）。此外，Peer Connection提供創建媒體協商的方法和屬性，如Offer/Answer消息構建方法（createOffer/createAnswer）及SDP屬性設置（setLocal Description/setRemote Description）等。

2.3 RTCWeb基于HTML5呈現方式

W3C WebRTC工作組對于媒體流的訪問和呈現使用HTML5 video和audio標簽[2]，這兩個新標簽提供了在瀏覽器中不使用插件播放視頻和音頻的特性，這正是HTML5區別于先前版本的顯著特征。非HTML5的瀏覽器一般安裝flash插件播放媒體，正確播放媒體需要使用和