• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

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

      2013-02-28 03:04:54屈振華李慧云楊新章龍顯軍
      電信科學(xué) 2013年1期
      關(guān)鍵詞:信令開(kāi)發(fā)者瀏覽器

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

      (中國(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

      猜你喜歡
      信令開(kāi)發(fā)者瀏覽器
      SLS字段在七號(hào)信令中的運(yùn)用
      反瀏覽器指紋追蹤
      電子制作(2019年10期)2019-06-17 11:45:14
      移動(dòng)信令在交通大數(shù)據(jù)分析中的應(yīng)用探索
      基于信令分析的TD-LTE無(wú)線網(wǎng)絡(luò)應(yīng)用研究
      LTE網(wǎng)絡(luò)信令采集數(shù)據(jù)的分析及探討
      16%游戲開(kāi)發(fā)者看好VR
      CHIP新電腦(2016年3期)2016-03-10 13:06:42
      環(huán)球?yàn)g覽器
      再見(jiàn),那些年我們嘲笑過(guò)的IE瀏覽器
      iOS開(kāi)發(fā)者調(diào)查
      電腦迷(2015年8期)2015-05-30 12:27:10
      iOS開(kāi)發(fā)者調(diào)查
      電腦迷(2015年4期)2015-05-30 05:24:09
      宣城市| 津南区| 湛江市| 兰坪| 玛曲县| 铜山县| 武定县| 南丹县| 舒兰市| 大姚县| 什邡市| 阿克苏市| 清徐县| 丰镇市| 营口市| 库伦旗| 饶阳县| 固阳县| 永年县| 龙胜| 高雄县| 西贡区| 洛川县| 宜州市| 凉城县| 名山县| 正定县| 于田县| 江门市| 宁晋县| 称多县| 陆河县| 武鸣县| 綦江县| 友谊县| 榆林市| 海南省| 贵港市| 胶南市| 花莲县| 莱西市|