WebRTC關鍵技術分析及運營商引入策略研究

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

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

1 引言

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

2 WebRTC關鍵技術

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

圖1 瀏覽器側功能架構

2.1 信令層面關鍵技術

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

圖2 信令協議關系

（1）承載協議

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

（2）信令協議

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

2.2 媒體處理層關鍵技術

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

（1）媒體采集和播放

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

（2）媒體增強

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

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

（3）媒體編碼

Google實現的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）針對互聯網分組丟失問題采用了分組丟失隱藏技術，配合GIPS獨有的NetEQ技術，有效地提高了分組丟失網絡下的通話體驗。其中特別值得關注的是Opus編碼，其由Mozilla和Xiph.org基金會開發，是一種窄帶到全頻段的音頻編解碼器，支持動態可調的碼率、幀長和音頻帶寬，是目前最先進的音頻編碼器之一。Opus作為一種全能型的音頻編碼器，很可能在未來全面取代其他編碼器，成為WebRTC的首選。Opus也面臨著復雜度較高、缺少硬件實現以及專利糾紛等問題，需要時間進一步檢驗。

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

（4）網絡傳輸

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

3 WebRTC業務模式

WebRTC目前有兩種主要的業務提供模式：P2P方式和Web2 Server方式。

（1）P2P方式

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

圖3 P2P方式組網

（2）Web2 Server方式

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

4 WebRTC對運營商的影響

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

圖4 Web2 Server方式組網

4.1 WebRTC帶來的新挑戰

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

（1）加劇通信碎片化趨勢，分流運營商的傳統語音業務

OTT業務的出現，已經促使通信的碎片化，并分流了運營商的語音業務；而WebRTC技術允許開發者在網頁中建立實時通信，使語音業務成為一種可以不依賴運營商平臺的原子能力。目前成熟的互聯網應用集成WebRTC后可能產生更豐富的應用形態，對現有運營商的融合通信產品產生的沖擊更大。可以預見，當WebRTC能夠簡單、低成本地集成到這些應用中時，通信的碎片化趨勢將加劇。

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

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

4.2 WebRTC帶來的新機遇

WebRTC技術將改變目前的OTT競爭格局，給傳統運營商應對新興OTT（如VoIP提供者）的威脅提供新的手段。如果能夠充分利用運營商的現有網絡、產品以及用戶資源優勢、快速反應能力，也可能將WebRTC作為運營商的業務創新點和贏利點。

（1）WebRTC可以降低新業務的開發部署成本

WebRTC具有易開發、跨平臺、部署成本低等優勢，可以吸引眾多的Web應用開發者基于運營商通信業務平臺開發應用。同時，將WebRTC和運營商的平臺、網絡優勢結合，可優化行業解決方案，幫助運營商降低終端應用開發成本，快速推出新的業務產品，并擴展和優化行業應用解決方案，補充運營商開放平臺的能力。

（2）以WebRTC推動IMS/VoLTE業務發展

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

4.3 運營商的應對策略

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

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

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

5 結束語

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

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