屈振華，李慧云，張 凌，楊新章，龍顯軍

（中國電信股份有限公司廣州研究院 廣州510630）

1 引言

Web技術(shù)正在面臨前所未有的巨大變革，Google最新倡導的WebRTC（web based real-time communication）技術(shù)正使得音視頻媒體的采集、播放及傳輸逐漸擺脫瀏覽器插件（如Adobe Flash Player、ActiveX、Java Applet等）的控制。Web應(yīng)用開發(fā)者僅需要進行簡單的JavaScript API調(diào)用，即可在兩個瀏覽器間輕松實現(xiàn)雙向多媒體實時通信。WebRTC技術(shù)的誕生源自基于互聯(lián)網(wǎng)的多媒體通信業(yè)務(wù)模式與Web應(yīng)用開發(fā)模式的有機結(jié)合，P2P的業(yè)務(wù)模式使得多媒體通信“碎片化”、“去中心化”的趨勢更加明顯，低成本、跨平臺、組網(wǎng)靈活等天生優(yōu)勢使得其更易于快速規(guī)模推廣?？梢灶A(yù)見，原本競爭激烈的多媒體實時通信市場即將面臨新一輪的洗牌，傳統(tǒng)運營商在這場變革中將何去何從？本文將分別介紹WebRTC在信令和媒體處理方面的關(guān)鍵技術(shù)，分析WebRTC的業(yè)務(wù)模式和可能對傳統(tǒng)運營商帶來的沖擊，并就運營商引入WebRTC的策略提出建議。

2 WebRTC關(guān)鍵技術(shù)

WebRTC技術(shù)框架最初被設(shè)計用于實現(xiàn)瀏覽器間的P2P通信，現(xiàn)有規(guī)范[1,2]主要定義了瀏覽器側(cè)（客戶端）的接口與交互方式。如圖1所示，WebRTC瀏覽器側(cè)的功能模塊至少包括音頻引擎、視頻引擎、網(wǎng)絡(luò)傳輸、WebRTC的本地API以及對音頻采集、視頻采集和網(wǎng)絡(luò)I/O的接口。瀏覽器需要實現(xiàn)音頻采集、視頻采集、網(wǎng)絡(luò)I/O的具體業(yè)務(wù)邏輯和功能模塊，并通過統(tǒng)一、與平臺無關(guān)的native API與JavaScript API向本地或Web應(yīng)用開發(fā)者提供功能調(diào)用。現(xiàn)有功能模塊大致可以劃分為信令層面與媒體層面兩部分。

圖1 瀏覽器側(cè)功能架構(gòu)

2.1 信令層面關(guān)鍵技術(shù)

WebRTC的信令消息由兩部分組成：一部分為承載協(xié)議，另一部分為信令協(xié)議，如圖2所示。

圖2 信令協(xié)議關(guān)系

（1）承載協(xié)議

目前WebRTC信令的承載協(xié)議可以采用Web Socket協(xié)議或傳統(tǒng)的HTTP，以支持瀏覽器和服務(wù)器或者瀏覽器和瀏覽器之間維持雙向的連接通道。Web Socket和Socket技術(shù)本質(zhì)上一樣，均是基于TCP的協(xié)議，所不同的是，在建立Web Socket連接之前，首先需要通過HTTP消息進行協(xié)商（HTTP經(jīng)過了擴展），協(xié)商完成后建立TCP雙向通道，直到客戶端或者服務(wù)器端的某一方主動關(guān)閉連接；基于HTTP的輪詢、長輪詢或流技術(shù)并不是真正的實時技術(shù)，只是在用Ajax方式模擬實時的效果，在每次客戶端和服務(wù)器端交互時都是一次HTTP請求和應(yīng)答的過程，而每一次的HTTP請求和應(yīng)答都帶有完整的HTTP頭信息。從傳輸?shù)臄?shù)據(jù)量大小、編程復(fù)雜度以及實時通信的效果看，Web Socket都優(yōu)于基于HTTP的輪詢、長輪詢和流技術(shù)。

（2）信令協(xié)議

WebRTC的信令協(xié)議并沒有硬性的標準，目前常用的信 令 協(xié) 議 包 括ROAP[3]、XMPP（Jingle）、SIP以 及JSEP[4]等。其中，JSEP從嚴格的角度來講，可以說是一種協(xié)議編程框架，它定義了一組JavaScript API以及調(diào)用的順序，在API中封裝了瀏覽器和應(yīng)用平臺/瀏覽器之間的信令交互過程，這樣開發(fā)者只需要關(guān)注業(yè)務(wù)邏輯和信令內(nèi)容的構(gòu)造，大大降低了開發(fā)的難度。在JSEP中，信令內(nèi)容可采用XMPP（Jingle協(xié)議）、SIP、ROAP或私有協(xié)議，因此可以說，JSEP僅是對信令協(xié)議的更高級封裝。

2.2 媒體處理層關(guān)鍵技術(shù)

WebRTC為實現(xiàn)多媒體實時通信提供了從音視頻采集、編解碼到網(wǎng)絡(luò)傳輸控制等一系列必要的軟件處理模塊，并將它們組成一個完整的媒體處理架構(gòu)。WebRTC采用了當前較為先進的音視頻編解碼格式，并根據(jù)VoIP應(yīng)用場景進行針對性優(yōu)化。在軟硬件架構(gòu)設(shè)計方面，也充分考慮到平臺間的差異以及今后的擴展能力。

（1）媒體采集和播放

WebRTC提供了多平臺下的媒體采集和播放功能，如音頻設(shè)備、視頻捕捉、視頻渲染等與硬件相關(guān)的模塊，根據(jù)不同的操作系統(tǒng)進行量身定制，并封裝為統(tǒng)一的API。例如，視頻渲染模塊就是根據(jù)Windows、Mac、Linux、Android等不同窗口系統(tǒng)，分別調(diào)用DirectX、Carbon、X11、Java等本地API進行視頻幀繪制。這部分API的維護需要對操作系統(tǒng)有較為透徹的認識，由開發(fā)者自行維護的難度很大，受限于Google、微軟、蘋果等操作系統(tǒng)開發(fā)商。

（2）媒體增強

WebRTC提供了包括高通濾波、噪聲抑制、回聲消除、自動增益控制、靜音檢測等語音增強功能。視頻處理包括顏色增強、去閃爍、下采樣、去噪。這些媒體信號處理操作在媒體編碼前或解碼后執(zhí)行，對媒體播放或編碼起到輔助作用，可以提升音視頻通信中的用戶體驗。雖然部分媒體采集/播放設(shè)備或操作系統(tǒng)也提供類似功能，但考慮到不同設(shè)備商或系統(tǒng)平臺間的驅(qū)動及接口差異，WebRTC對這些功能提供了軟件實現(xiàn)，以便在無法使用硬件時進行補充。

WebRTC媒體增強模塊的特點是實現(xiàn)代碼的高度整合，例如，共用部分數(shù)據(jù)結(jié)構(gòu)、宏、底層匯編優(yōu)化指令等，雖然會增加代碼間的耦合度，但有利于代碼的進一步優(yōu)化。例如，只需要對部分通用函數(shù)，如卷積、相關(guān)等，采用SSE、NEON等SIMD指令進行優(yōu)化，就可以實現(xiàn)整體性能的提升。PC平臺與嵌入式平臺間處理性能的差異，導致WebRTC需要對不同平臺分別提供不同的算法實現(xiàn)或代碼優(yōu)化，但受嵌入式設(shè)備硬件處理能力所限，目前仍然存在一定的性能瓶頸，需要在未來進一步完善。

（3）媒體編碼

Google實現(xiàn)的WebRTC音頻引擎中集成了G.711a/u、iLBC（RFC 3951）[5]、iSAC、G.722[6]、Opus（RFC 6716）[7]等音頻編解碼器，其中G.711a/u、iLBC屬于窄帶語音編碼器，而iSAC、G.722、Opus屬于寬帶語音/音頻編碼器。部分編碼器（如iLBC、Opus）針對互聯(lián)網(wǎng)分組丟失問題采用了分組丟失隱藏技術(shù)，配合GIPS獨有的NetEQ技術(shù)，有效地提高了分組丟失網(wǎng)絡(luò)下的通話體驗。其中特別值得關(guān)注的是Opus編碼，其由Mozilla和Xiph.org基金會開發(fā)，是一種窄帶到全頻段的音頻編解碼器，支持動態(tài)可調(diào)的碼率、幀長和音頻帶寬，是目前最先進的音頻編碼器之一。Opus作為一種全能型的音頻編碼器，很可能在未來全面取代其他編碼器，成為WebRTC的首選。Opus也面臨著復(fù)雜度較高、缺少硬件實現(xiàn)以及專利糾紛等問題，需要時間進一步檢驗。

相對音頻編解碼而言，不同視頻編碼間的差異性較小，專利成為影響編碼標準成功的重要因素。VP8視頻編碼（RFC 6386）[8]源自被Google收購的On2 Technologies公司，現(xiàn)已成為WebM開源項目的一部分。免費與開源是VP8格式的最大優(yōu)勢，得到Chrome、Firefox、Opera等廠商的普遍支持，自然成為WebRTC的首選。事實上，WebRTC對視頻編碼的選用，一直存在VP8和H.264之爭。Google雖然明確表示其Chrome瀏覽器中的WebRTC不會支持H.264，但H.264由于牽涉眾多業(yè)界巨頭的商業(yè)利益，軟硬件實現(xiàn)都要比VP8成熟得多，已經(jīng)成為視頻通信事實上的標準；而VP8最大的問題就是和H.264實在太像，其使用的許多技術(shù)（如宏塊劃分、幀內(nèi)預(yù)測等），幾乎是照搬H.264的方法，由此也帶來很多專利糾紛。最近Google與MPEG-LA已經(jīng)達成專利授權(quán)協(xié)議，進一步掃除了VP8應(yīng)用的障礙，但諾基亞又提出對VP8的專利侵權(quán)起訴。Google也在積極推動新一代編碼技術(shù)VP9的應(yīng)用，在將要發(fā)布的Chrome 28中支持VP9。

（4）網(wǎng)絡(luò)傳輸

WebRTC的媒體流傳輸采用標準的RTP/SRTP（secure RTP，RFC 3711），并提供一種基于ICE（STUN+TURN）[9～11]的私網(wǎng)穿越機制。由于WebRTC采用了全自動的網(wǎng)絡(luò)傳輸控制，用戶幾乎無需對媒體流的傳輸過程進行干預(yù)。盡管WebRTC為點對點的通話場景而設(shè)計，但RTP/SRTP流既可以用于單播也可以用于實現(xiàn)多播，這意味著通過媒體流重定向或拆分/匯聚，有可能實現(xiàn)視頻監(jiān)控、媒體廣播、視頻會議等目前不具備的新功能。對于運營商而言，需要特別注意的一點是，WebRTC默認采用SRTP進行媒體流傳輸，這一方面提高了媒體傳輸?shù)陌踩?，但同時也造成今后的監(jiān)管風險。

3 WebRTC業(yè)務(wù)模式

WebRTC目前有兩種主要的業(yè)務(wù)提供模式：P2P方式和Web2 Server方式。

（1）P2P方式

如圖3所示，在P2P方式下，Web瀏覽器之間進行協(xié)議和媒體的點對點通信交互，媒體流可以取道最短路由，特別適合局域網(wǎng)、企業(yè)網(wǎng)等帶寬有保證的通信場景。這種方式受到以Google為首的新興互聯(lián)網(wǎng)商、虛擬運營商、應(yīng)用提供者以及個人開發(fā)者的青睞，應(yīng)用的場景包括在線客服、遠程教學、培訓、外勤匯報、垂直網(wǎng)站等。

圖3 P2P方式組網(wǎng)

（2）Web2 Server方式

如圖4所示，在Web2 Server方式下，服務(wù)提供商需要部署WebRTC服務(wù)器實現(xiàn)WebRTC之間的信令互通，并可通過網(wǎng)關(guān)與其他業(yè)務(wù)系統(tǒng)（如傳統(tǒng)PSTN/GSM/CDMA或IMS等）互通。這種方案需要考慮服務(wù)器架設(shè)、網(wǎng)關(guān)部署、數(shù)據(jù)承載等一系列問題，主要陣營是傳統(tǒng)運營商、通信設(shè)備制造商、企業(yè)解決方案提供商以及部分OTT企業(yè)。應(yīng)用場景包括實時會議系統(tǒng)、呼叫中心、融合信息服務(wù)、社交應(yīng)用、視頻監(jiān)控等。

4 WebRTC對運營商的影響

WebRTC為運營商帶來的影響是多方面的，既帶來新的挑戰(zhàn)，也提供了新的機遇。

圖4 Web2 Server方式組網(wǎng)

4.1 WebRTC帶來的新挑戰(zhàn)

WebRTC大幅降低了多媒體實時通信應(yīng)用的開發(fā)門檻，為市場帶來更多新的競爭對手，直接沖擊運營商的語音業(yè)務(wù)。

（1）加劇通信碎片化趨勢，分流運營商的傳統(tǒng)語音業(yè)務(wù)

OTT業(yè)務(wù)的出現(xiàn)，已經(jīng)促使通信的碎片化，并分流了運營商的語音業(yè)務(wù)；而WebRTC技術(shù)允許開發(fā)者在網(wǎng)頁中建立實時通信，使語音業(yè)務(wù)成為一種可以不依賴運營商平臺的原子能力。目前成熟的互聯(lián)網(wǎng)應(yīng)用集成WebRTC后可能產(chǎn)生更豐富的應(yīng)用形態(tài)，對現(xiàn)有運營商的融合通信產(chǎn)品產(chǎn)生的沖擊更大?？梢灶A(yù)見，當WebRTC能夠簡單、低成本地集成到這些應(yīng)用中時，通信的碎片化趨勢將加劇。

（2）“去中心化”的趨勢更加明顯

在WebRTC的體系架構(gòu)中，平臺的作用被弱化，媒體協(xié)商可以不通過平臺完成。WebRTC需要平臺協(xié)助的功能集成到已有的業(yè)務(wù)平臺中，而不需要額外部署網(wǎng)元。這種業(yè)務(wù)模式大大降低了部署的難度和成本，也使得一些運營商的傳統(tǒng)優(yōu)勢業(yè)務(wù)可以不依賴運營商的業(yè)務(wù)平臺實現(xiàn)（如呼叫中心等），使得運營商淪為數(shù)據(jù)通道。

4.2 WebRTC帶來的新機遇

WebRTC技術(shù)將改變目前的OTT競爭格局，給傳統(tǒng)運營商應(yīng)對新興OTT（如VoIP提供者）的威脅提供新的手段。如果能夠充分利用運營商的現(xiàn)有網(wǎng)絡(luò)、產(chǎn)品以及用戶資源優(yōu)勢、快速反應(yīng)能力，也可能將WebRTC作為運營商的業(yè)務(wù)創(chuàng)新點和贏利點。

（1）WebRTC可以降低新業(yè)務(wù)的開發(fā)部署成本

WebRTC具有易開發(fā)、跨平臺、部署成本低等優(yōu)勢，可以吸引眾多的Web應(yīng)用開發(fā)者基于運營商通信業(yè)務(wù)平臺開發(fā)應(yīng)用。同時，將WebRTC和運營商的平臺、網(wǎng)絡(luò)優(yōu)勢結(jié)合，可優(yōu)化行業(yè)解決方案，幫助運營商降低終端應(yīng)用開發(fā)成本，快速推出新的業(yè)務(wù)產(chǎn)品，并擴展和優(yōu)化行業(yè)應(yīng)用解決方案，補充運營商開放平臺的能力。

（2）以WebRTC推動IMS/VoLTE業(yè)務(wù)發(fā)展

WebRTC技術(shù)的應(yīng)用可能推進IMS業(yè)務(wù)，特別是VoLTE的部署。國內(nèi)IMS網(wǎng)絡(luò)經(jīng)歷多年發(fā)展，終端成本居高不下、用戶遷移緩慢一直是其發(fā)展面臨的兩大難題。通過將IMS和WebRTC結(jié)合，可以極大地降低IMS終端的開發(fā)門檻，為用戶提供基于寬帶、低時延網(wǎng)絡(luò)環(huán)境的優(yōu)質(zhì)多媒體解決方案。如果能夠與未來LTE網(wǎng)絡(luò)的發(fā)展策略切合，實現(xiàn)VoLTE業(yè)務(wù)的快速上線，將能夠為運營商帶來巨大的利益。

4.3 運營商的應(yīng)對策略

最近幾年，運營商一直在學習和研究互聯(lián)網(wǎng)的業(yè)務(wù)開發(fā)和運營模式，但受限于運營商在互聯(lián)網(wǎng)領(lǐng)域的薄弱基礎(chǔ)，一直沒有有競爭力的互聯(lián)網(wǎng)應(yīng)用產(chǎn)品，WebRTC的應(yīng)用場景可以發(fā)揮出運營商的優(yōu)勢，找到Telco-OTT（運營商-OTT）業(yè)務(wù)的切入點，改變目前的現(xiàn)狀。同時也要注意到，WebRTC目前仍處于發(fā)展階段，存在的技術(shù)、監(jiān)管和產(chǎn)品/解決方案成熟度等風險以及貢獻方態(tài)度迥異可能引起技術(shù)方向的不確定性，使得運營商在積極參與WebRTC研發(fā)的同時，需維持謹慎的態(tài)度。因此，采用循序漸進、從點到面的引入策略是比較合適的選擇。

建設(shè)初期可以考慮從增值業(yè)務(wù)入手，采用基于Web2 Server/網(wǎng)關(guān)方案，通過與現(xiàn)有網(wǎng)絡(luò)（如IMS等）互通或者Telco-OTT方式，與現(xiàn)有業(yè)務(wù)形成互補。例如，可以通過IMS提供基礎(chǔ)、有保障的VoLTE業(yè)務(wù)，以WebRTC方式提供Telco-OTT模式的增值業(yè)務(wù)以及擴展現(xiàn)有網(wǎng)絡(luò)和業(yè)務(wù)能力。從中長期來看，可以考慮把WebRTC技術(shù)作為富媒體融合通信的基礎(chǔ)解決方案之一，使用WebRTC native API定制開發(fā)電信運營商自己的瀏覽器或服務(wù)器，實現(xiàn)功能更復(fù)雜的融合通信產(chǎn)品。

從市場需求方面分析，WebRTC技術(shù)在公眾客戶與企業(yè)客戶市場都可以有所作為。對于公眾用戶而言，主要從拉升流量方面考慮；對于企業(yè)用戶而言，主要從更完善、更靈活、更低成本的解決方案考慮。公眾市場可以考慮間接方式，即提供SDK/API分組給Web應(yīng)用開發(fā)者，引入更多的開發(fā)者，將能力嵌入各種互聯(lián)網(wǎng)應(yīng)用中，以吸引用戶，拉動流量持續(xù)增長。企業(yè)市場可以采用直接提供服務(wù)的模式，著力發(fā)展垂直行業(yè)市場，如基于Web語音/視頻呼叫、Web會議、在線培訓以及企業(yè)內(nèi)部的協(xié)同業(yè)務(wù)。

5 結(jié)束語

目前，WebRTC技術(shù)正處于其成長期，在標準、技術(shù)實現(xiàn)上都不成熟，正是運營商切入的最佳階段。中國電信在多媒體業(yè)務(wù)領(lǐng)域（無論是終端還是平臺方面）擁有豐富的經(jīng)驗，及時切入WebRTC的研究，引導WebRTC的技術(shù)發(fā)展方向，就有可能抓住新的發(fā)展機會。WebRTC作為一項新型技術(shù)，從產(chǎn)生到真正產(chǎn)品化，還有許多細節(jié)需要完善，這也有待于進一步的觀察和更深入的研究。

1 Bergkvist A,Burnett D C,Jennings C,et al.WebRTC 1.0:Real-time Communication Between BrowsersW3C Editor’s Draft 03,2013

2 Burnett D C,Narayanan A.Media Capture and Streams.W3C Editor’s Draft 30,2013

3 Jennings C,Rosenberg J,Uberti J,et al.RTCWeb Offer/Answer Protocol(ROAP),2011

4 Uberti J,Jennings C.JavaScript Session Establishment Protocol(JSEP),2012

5 Andersen S,Telio D A,Astrom H,et al.Internet Low Bit Rate Codec(iLBC).RFC3951,2013

6 ITU-T Recommendation G.722.7 kHz Audio-Coding Within 64 kbit/s,1988

7 Valin J M,Vos K,Terriberry T.Definition of the Opus Audio Codec.RFC6716,2012

8 Bankoski J,Koleszar J,Quillio L,et al.VP8 Data Format and Decoding Guide.RFC6386,2011

9 Rosenberg J,Mahy R,Matthews P,et al.Session Traversal Utilities for NAT(STUN).RFC5389,2008

10 Mahy P,Matthews P,Rosenberg J.Traversal Using Relays around NAT(TURN):Relay Extensions to Session Traversal Utilities for NAT(STUN).RFC5766,2010

11 Rosenberg J.Interactive Connectivity Establishment(ICE):a Protocol for Network Address Translator(NAT)Traversal for Offer/Answer Protocols.RFC5245,2010