WebRTC關(guān)鍵技術(shù)分析及運(yùn)營(yíng)商引入策略研究

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

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

1 引言

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

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

WebRTC技術(shù)框架最初被設(shè)計(jì)用于實(shí)現(xiàn)瀏覽器間的P2P通信，現(xiàn)有規(guī)范[1,2]主要定義了瀏覽器側(cè)（客戶端）的接口與交互方式。如圖1所示，WebRTC瀏覽器側(cè)的功能模塊至少包括音頻引擎、視頻引擎、網(wǎng)絡(luò)傳輸、WebRTC的本地API以及對(duì)音頻采集、視頻采集和網(wǎng)絡(luò)I/O的接口。瀏覽器需要實(shí)現(xiàn)音頻采集、視頻采集、網(wǎng)絡(luò)I/O的具體業(yè)務(wù)邏輯和功能模塊，并通過(guò)統(tǒng)一、與平臺(tái)無(wú)關(guān)的native API與JavaScript API向本地或Web應(yīng)用開(kāi)發(fā)者提供功能調(diào)用?，F(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連接之前，首先需要通過(guò)HTTP消息進(jìn)行協(xié)商（HTTP經(jīng)過(guò)了擴(kuò)展），協(xié)商完成后建立TCP雙向通道，直到客戶端或者服務(wù)器端的某一方主動(dòng)關(guān)閉連接；基于HTTP的輪詢、長(zhǎng)輪詢或流技術(shù)并不是真正的實(shí)時(shí)技術(shù)，只是在用Ajax方式模擬實(shí)時(shí)的效果，在每次客戶端和服務(wù)器端交互時(shí)都是一次HTTP請(qǐng)求和應(yīng)答的過(guò)程，而每一次的HTTP請(qǐng)求和應(yīng)答都帶有完整的HTTP頭信息。從傳輸?shù)臄?shù)據(jù)量大小、編程復(fù)雜度以及實(shí)時(shí)通信的效果看，Web Socket都優(yōu)于基于HTTP的輪詢、長(zhǎng)輪詢和流技術(shù)。

（2）信令協(xié)議

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

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

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

（1）媒體采集和播放

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

（2）媒體增強(qiáng)

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

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

（3）媒體編碼

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

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

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

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

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

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

（1）P2P方式

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

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

（2）Web2 Server方式

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

4 WebRTC對(duì)運(yùn)營(yíng)商的影響

WebRTC為運(yùn)營(yíng)商帶來(lái)的影響是多方面的，既帶來(lái)新的挑戰(zhàn)，也提供了新的機(jī)遇。

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

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

WebRTC大幅降低了多媒體實(shí)時(shí)通信應(yīng)用的開(kāi)發(fā)門檻，為市場(chǎng)帶來(lái)更多新的競(jìng)爭(zhēng)對(duì)手，直接沖擊運(yùn)營(yíng)商的語(yǔ)音業(yè)務(wù)。

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

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

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

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

4.2 WebRTC帶來(lái)的新機(jī)遇

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

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

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

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

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

4.3 運(yùn)營(yíng)商的應(yīng)對(duì)策略

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

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

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

5 結(jié)束語(yǔ)

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

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