您當(dāng)前的位置是：  首頁(yè) > 新聞 > 文章精選 >
 首頁(yè) > 新聞 > 文章精選 >

完整WebRTC技術(shù)及應(yīng)用概要

2019-01-07 09:30:39   作者：朱利中（james.zhu）   來(lái)源：CTI論壇   評(píng)論：0 　點(diǎn)擊：

　　Web Real-Time Communication（WebRTC）是最近幾年非常熱門(mén)的一項(xiàng)新的基于瀏覽器的技術(shù)，很多VoIP的廠家和應(yīng)用集成廠家的解決方案中都逐漸支持了WebRTC技術(shù)。WebRTC技術(shù)通過(guò)對(duì)瀏覽器或者移動(dòng)終端應(yīng)用，結(jié)合API接口，實(shí)現(xiàn)了視頻，語(yǔ)音功能。當(dāng)然，WebRTC受到如此多重視，當(dāng)然也離不開(kāi)主要的推動(dòng)者Google，微軟，Mozilla等大牌廠家的鼎力支持，以及幾個(gè)著名的協(xié)議組織，例如，W3C和IETF的協(xié)助。
　　雖然，網(wǎng)絡(luò)上有很多關(guān)于WebRTC的文章，這些文章通過(guò)不同的角度對(duì)WebRTC做了非常詳細(xì)的介紹，WebRTC官方網(wǎng)站也發(fā)布了有很多的文檔。但是，很多網(wǎng)上的文章比較零散，討論的角度都不一樣。另外，很多權(quán)威的文檔和紙質(zhì)書(shū)基本上都是以英文出版，一些讀者的英文閱讀能力沒(méi)有那么高的話，可能影響對(duì)技術(shù)的消化吸收。為了給中國(guó)讀者提供一個(gè)比較全面的完整的關(guān)于WebRTC的技術(shù)以及應(yīng)用概要，筆者希望通過(guò)一個(gè)完整的篇幅，對(duì)WebRTC技術(shù)做一個(gè)比較系統(tǒng)，完整地描述介紹，其內(nèi)容包括從WebRTC背景知識(shí)，媒體流，相關(guān)的協(xié)議棧，NAT處理，安全以及隱身設(shè)置，WebRTC當(dāng)前的問(wèn)題以及未來(lái)的提升，WebRTC用戶使用場(chǎng)景，和開(kāi)源WebRTC媒體服務(wù)器以及視頻會(huì)議，WebRTC測(cè)試工具等知識(shí)點(diǎn)，讓普通讀者能夠通過(guò)一篇文章就對(duì)WebRTC技術(shù)有一個(gè)非常清晰的思路，為進(jìn)一步學(xué)習(xí)WebRTC技術(shù)做一個(gè)有效鋪墊，讀者可以快速進(jìn)入到真正的WebRTC技術(shù)應(yīng)用開(kāi)發(fā)中。在十一個(gè)章節(jié)中，筆者會(huì)根據(jù)WebRTC技術(shù)的架構(gòu)以及相關(guān)的應(yīng)用做一個(gè)完整的介紹。
　　1、WebRTC的技術(shù)背景介紹
　　首先讓我們簡(jiǎn)單了解一下基本的通信背景知識(shí)。如果從實(shí)時(shí)通信和語(yǔ)音協(xié)議的發(fā)展來(lái)看，最早的語(yǔ)音通信協(xié)議應(yīng)該發(fā)生在1977年，人們把實(shí)時(shí)通信技術(shù)通過(guò)Network Voice Protocol（NVP-rfc741）在網(wǎng)絡(luò)上應(yīng)用，并且演示了其技術(shù)的可用性。在語(yǔ)音發(fā)展過(guò)程中，實(shí)時(shí)通信開(kāi)始也經(jīng)歷了多個(gè)歷史階段，并且結(jié)合其他的技術(shù)逐漸實(shí)現(xiàn)了突破。以下是一個(gè)關(guān)于語(yǔ)音技術(shù)的部分階段的發(fā)展進(jìn)程。
　　如下圖示例所示，最初的工作模型也相對(duì)比較簡(jiǎn)單，隨著技術(shù)的不斷完善和協(xié)議的修改，今天的語(yǔ)音技術(shù)已經(jīng)出現(xiàn)了很大的突破。具體關(guān)于NVP的規(guī)范，讀者可以查閱rfc741獲得詳情。


　　在提到實(shí)時(shí)通信技術(shù)或者WebRTC技術(shù)，我們還要簡(jiǎn)單介紹一下實(shí)時(shí)傳輸協(xié)議RTP，此技術(shù)最早在1992年左右開(kāi)始使用，1996年作為一個(gè)標(biāo)準(zhǔn)發(fā)布。目前RTP是VoIP，SIP或者WebRTC的其中一個(gè)部分。
　　除了RTP協(xié)議以外，H323和SIP協(xié)議也是我們進(jìn)入討論WebRTC之前需要介紹的背景知識(shí)。H323在1996年有ITU發(fā)布，SIP在1999年由IETF發(fā)布。在最近幾十年的語(yǔ)音視頻領(lǐng)域，這兩種協(xié)議在語(yǔ)音和視頻技術(shù)扮演者非常重要的角色。當(dāng)然，現(xiàn)在被用戶和市場(chǎng)認(rèn)可的是SIP協(xié)議，H323用戶逐漸變少。


　　WebRTC受到青睞原因很多，我們會(huì)在下面的章節(jié)中加以介紹。其主要原因是它的易用性，并且可以借用當(dāng)前用戶瀏覽器的其他媒體設(shè)備，例如麥克風(fēng)和攝像頭，通過(guò)瀏覽器的API接口直接訪問(wèn)這些網(wǎng)絡(luò)資源，用戶無(wú)需再安裝下載其他的插件來(lái)獲得對(duì)網(wǎng)絡(luò)資源的支持。WebRTC也可以實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的網(wǎng)絡(luò)互動(dòng)，可以避免遠(yuǎn)程服務(wù)器的網(wǎng)絡(luò)訪問(wèn)問(wèn)題。特別是VoLTE網(wǎng)絡(luò)環(huán)境中，語(yǔ)音可以通過(guò)數(shù)據(jù)通道來(lái)實(shí)現(xiàn)，這樣就會(huì)極大方便終端用戶的語(yǔ)音視頻通信。另外，現(xiàn)在很多的在線游戲也可以通過(guò)瀏覽器的形式展現(xiàn)游戲場(chǎng)景，用戶實(shí)現(xiàn)了和同學(xué)，朋友通過(guò)語(yǔ)音，數(shù)據(jù)和視頻同時(shí)進(jìn)行互動(dòng)交流。
　　現(xiàn)在，我們簡(jiǎn)單介紹一下WebRTC的功能實(shí)現(xiàn)。WebRTC的功能包括以上幾個(gè)核心的模塊和API接口。用戶瀏覽器通過(guò)和HTML，其他的腳本語(yǔ)言和客戶端的接口進(jìn)行調(diào)用。特別注意，在瀏覽器的RTC功能中，特別包括了傳輸?shù)木幋a，回聲處理等功能。其他的媒體數(shù)據(jù)可以通過(guò)RTC功能和WebRTC實(shí)現(xiàn)通信。
　　WebRTC受到市場(chǎng)的認(rèn)可有很多原因。它主要包括以下幾個(gè)方面的原因：
  • 平臺(tái)和設(shè)備的獨(dú)立。開(kāi)發(fā)人員可以通過(guò)支持WebRTC的瀏覽器開(kāi)發(fā)基于WebRTC的各種應(yīng)用，無(wú)需擔(dān)心終端和操作系統(tǒng)層面的兼容性問(wèn)題。另外，WebRTC也提供了標(biāo)準(zhǔn)的API（W3C）和其標(biāo)準(zhǔn)的協(xié)議支持（IETF）避免了平臺(tái)兼容性的問(wèn)題。
  • 語(yǔ)音和視頻的安全處理， WebRTC通過(guò)SRTP對(duì)語(yǔ)音和視頻進(jìn)行加密處理。用戶使用瀏覽器登錄訪問(wèn)語(yǔ)音和視頻需要比較安全的設(shè)置要求，滿足了用戶場(chǎng)景的安全要求（例如，在無(wú)安全保障的wifi環(huán)境下的語(yǔ)音和視頻），其他人不能對(duì)其進(jìn)行監(jiān)聽(tīng)。
  • 支持高級(jí)語(yǔ)言和視頻處理，WebRTC支持了最新的編碼，語(yǔ)音支持了Opus，視頻支持了VP8。內(nèi)置的編碼排除了其他第三方下載的安全隱患，同時(shí)能夠支持網(wǎng)絡(luò)環(huán)境的調(diào)整，實(shí)現(xiàn)了比較好的語(yǔ)音或視頻質(zhì)量。
  • 支持可靠性傳輸創(chuàng)建，WebRTC提供了可靠性傳輸方式，包括了在NAT環(huán)境下仍然可以實(shí)現(xiàn)傳輸?shù)姆�(wěn)定性。
  • 支持多媒體流處理，WebRTC提供了多媒體和多資源的聚和，提供了RTP和SDP的拓展。
  • 支持不同網(wǎng)絡(luò)環(huán)境調(diào)節(jié)，因?yàn)閃ebRTC在網(wǎng)絡(luò)平臺(tái)執(zhí)行，所以對(duì)網(wǎng)絡(luò)環(huán)境和帶寬非常敏感。它可以自己檢測(cè)，調(diào)整網(wǎng)絡(luò)環(huán)境和帶寬需求，避免網(wǎng)絡(luò)擁塞。它通過(guò)RTCP和SAVPF來(lái)保障此功能。
  • 和VoIP語(yǔ)音視頻有比較好的兼容性，WebRTC實(shí)現(xiàn)了和其他媒體的兼容性操作，包括了SIP，Jingle和XMPP對(duì)接。同時(shí)，如果需要和傳統(tǒng)的其他協(xié)議對(duì)接的話，可以通過(guò)WebRTC 網(wǎng)關(guān)來(lái)實(shí)現(xiàn)兼容性的流暢性，保證和傳統(tǒng)協(xié)議的兼容性。
　　使用WebRTC對(duì)開(kāi)發(fā)人員和用戶有以下幾個(gè)方面的好處：
  • 開(kāi)發(fā)人員可以無(wú)需擔(dān)心平臺(tái)的兼容性，實(shí)現(xiàn)無(wú)縫集成。
  • 開(kāi)發(fā)人員可以使用簡(jiǎn)單的API接口就可以實(shí)現(xiàn)應(yīng)用開(kāi)發(fā)。
  • 開(kāi)發(fā)人員無(wú)需擔(dān)心NAT帶來(lái)的問(wèn)題。
  • 開(kāi)發(fā)人員可以使用比較高級(jí)的編碼資源，無(wú)需承擔(dān)商業(yè)許可證費(fèi)用。
  • 用戶無(wú)需安裝即可使用。
  • 用戶所有通信都是加密的。
  • 用戶可以實(shí)現(xiàn)可靠性傳輸。
  • 用戶可以使用高清語(yǔ)音和視頻。
  • 用戶可以選擇更多的實(shí)時(shí)通信手段。
　　接下來(lái)，我們簡(jiǎn)單介紹一下WebRTC的著名三角形拓?fù)涫纠?/div>
　　以上示例是一個(gè)非常普遍的應(yīng)用流程示意圖，用戶可以到官方網(wǎng)站獲得其流程的其他說(shuō)明。特別指出的是，在語(yǔ)音通信環(huán)境中，可能很多用戶關(guān)心的是如何實(shí)現(xiàn)和SIP，PSTN的網(wǎng)絡(luò)聚合。我們?cè)倭信e幾個(gè)和語(yǔ)音環(huán)境相關(guān)的集成方案示例。


　　如果WebRTC實(shí)現(xiàn)對(duì)PSTN呼叫的話，事實(shí)上還是經(jīng)過(guò)SIP/PSTN網(wǎng)關(guān)的轉(zhuǎn)換，可以支持FXO/FXS或者E1接入方式。
　　如果一些IPPBX（舊版本的IPPBX）沒(méi)有支持WebRTC的話，或者為了避免WebRTC對(duì)接帶來(lái)的問(wèn)題，也可以通過(guò)WebRTC網(wǎng)關(guān)來(lái)對(duì)接傳統(tǒng)的SIP/IPPBX，然后實(shí)現(xiàn)IPPBX+WebRTC網(wǎng)關(guān)+瀏覽器WebRTC應(yīng)用的應(yīng)用場(chǎng)景。筆者在兩年前使用FreePBX-2.5 結(jié)合portSIP WebRTC 網(wǎng)關(guān)實(shí)現(xiàn)的一個(gè)案例。


　　在以上示例中，IPPBX使用的是FreePBX開(kāi)源的企業(yè)IPPBX，PSTN接入可以使用語(yǔ)音板卡或者PSTN語(yǔ)音網(wǎng)關(guān)或者無(wú)線網(wǎng)關(guān)來(lái)實(shí)現(xiàn)，通過(guò)portsip WebRTC網(wǎng)關(guān)實(shí)現(xiàn)和瀏覽器終端的對(duì)接。因?yàn)榭蛻舳艘�，接入方使用了鼎信通達(dá)的無(wú)線網(wǎng)關(guān)實(shí)現(xiàn)，使用了SIM卡直接呼叫。
　　2、WebRTC 媒體流處理
　　在WebRTC環(huán)境中，每個(gè)終端都不同，它們具有各自的訪問(wèn)方式。以下示例說(shuō)明了各種終端進(jìn)行WebRTC媒體流處理的流程。有的終端可能在家庭網(wǎng)絡(luò)環(huán)境，有的終端可能在公司內(nèi)網(wǎng)環(huán)境，有的終端可能在咖啡館使用wifi上網(wǎng)。應(yīng)用服務(wù)器則在公網(wǎng)環(huán)境中。
　　如果在網(wǎng)絡(luò)一般正常的網(wǎng)絡(luò)環(huán)境中，如果沒(méi)有WebRTC的話，兩個(gè)終端之間的通信只能通過(guò)頁(yè)面服務(wù)器來(lái)做一個(gè)路由處理和交換。但是，如果服務(wù)器和終端之間存在網(wǎng)絡(luò)穩(wěn)定性問(wèn)題或者距離比較遠(yuǎn)的話，那終端之間的實(shí)時(shí)通信就很難得到保證。
　　如果瀏覽器支持了WebRTC的話，兩個(gè)終端之間可以不通過(guò)服務(wù)器端進(jìn)行路由，同時(shí)可以解決NAT問(wèn)題，終端之間可以直接實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通信，這樣就保證了實(shí)時(shí)通信的穩(wěn)定性。
　　在上面的介紹中，我們討論了WebRTC中的NAT問(wèn)題。關(guān)于NAT問(wèn)題，我們?cè)谇懊娴暮芏嗾鹿?jié)中已經(jīng)多次提及，這里不再過(guò)多對(duì)NAT做說(shuō)明。今天，我們重點(diǎn)討論WebRTC中的NAT問(wèn)題。WebRTC內(nèi)置的策略機(jī)制（Interactive Connectivity Establishment ）用來(lái)解決NAT問(wèn)題。在點(diǎn)對(duì)點(diǎn)的通信中，ICE通過(guò)打洞的方式實(shí)現(xiàn)了點(diǎn)對(duì)點(diǎn)的通信。這里，ICE的主要目的是通過(guò)不同服務(wù)器之間的中轉(zhuǎn)，找到兩個(gè)終端之間連接的最佳路徑。大部分情況下，ICE使用STUN就可以實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的互通，有時(shí)也需要借助TURN服務(wù)器實(shí)現(xiàn)轉(zhuǎn)發(fā)來(lái)實(shí)現(xiàn)。ICE對(duì)Peers的檢測(cè)配對(duì)需要經(jīng)過(guò)六個(gè)步驟，rfc5245 對(duì)ICE 檢測(cè)有如下定義：
  1.  Sort the candidate pairs in priority order.
  2.  Send checks on each candidate pair in priority order.
  3.  Acknowledge checks received from the other agent.
　　在第五步時(shí)，需要瀏覽器同時(shí)檢查STUN數(shù)據(jù)。如下圖所示：
　　STUN 服務(wù)器的查詢過(guò)程如下：
　　當(dāng)STUN 服務(wù)器查詢不到兩個(gè)終端的話，需要借助于TURN 服務(wù)器來(lái)實(shí)現(xiàn)。這里讀者一定要注意，NAT的場(chǎng)景不同，使用的策略可能是不同的，我們這里僅說(shuō)明symmetric的NAT場(chǎng)景。
　　以下是用戶使用STUN和TURN的一個(gè)簡(jiǎn)單的對(duì)比，幫助讀者能夠更加清晰了解這兩個(gè)服務(wù)器的作用和部署成本。關(guān)于ICE的使用和具體參數(shù)屬性，筆者將在后續(xù)的章節(jié)中做非常詳細(xì)的介紹，用戶也可以查閱歷史文檔來(lái)做進(jìn)一步學(xué)習(xí)。筆者這里再次提醒，在WebRTC的呼叫過(guò)程中，大部分的呼叫失敗都是因?yàn)镮CE協(xié)商問(wèn)題，以上六個(gè)步驟是排查時(shí)需要特別注意到地方。
　　3、WebRTC 相關(guān)協(xié)議
　　WebRTC支持了很多RFC標(biāo)準(zhǔn)，這些組織完成了關(guān)于WebRTC的標(biāo)準(zhǔn)起草，API定義和一些相關(guān)的拓展協(xié)議。其中，三個(gè)組織需要讀者去關(guān)注，它們分別是IETF，W3C和RTCWEB。它們都有自己的官方網(wǎng)站，讀者可以查閱。WebRTC技術(shù)所使用的協(xié)議棧包括以下幾種，讀者可以僅關(guān)注應(yīng)用層和傳輸層即可。這些協(xié)議在RFC中都有各自的規(guī)范定義。比較重要的是ICE規(guī)范，關(guān)于ICE的規(guī)范，用戶可以查閱rfc5245。
　　因?yàn)槿诤贤ㄐ诺牟粩喟l(fā)展，WebRTC和SIP互通也變得非常重要，而且在企業(yè)融合通信中，需要接入PSTM或者企業(yè)UC的功能。因此，我們會(huì)花更多時(shí)間在討論WebRTC和SIP之間的關(guān)系及應(yīng)用中。
　　4、WebRTC相關(guān)草案
　　任何技術(shù)的發(fā)展都離不開(kāi)一些組織的推動(dòng)，這些組織完成了對(duì)技術(shù)規(guī)范的標(biāo)準(zhǔn)化制定。在上面的章節(jié)中，我們提到了RTCWEB工作組，這個(gè)組織對(duì)WEBRTC的一些功能正在起草一些新的草案（draft），還沒(méi)有形成正式的rfc規(guī)范。這些草案分別是：
  • Real Time Protocols for Browser-based Applications
  • Web Real-Time Communication Use-cases and Requirements
  • Web Real-Time Communication （WebRTC）: Media Transport and Use of RTP
  • WebRTC Security Architecture
  • Security Considerations for WebRTC
  • WebRTC Data Channels
  • WebRTC Data Channel Establishment Protocol
  • JavaScript Session Establishment Protocol
  • WebRTC Audio Codec and Processing Requirements
  • STUN Usage for Consent Freshness
  • Transports for RTCWEB
　　除了以上草案以外，RTCWEB還和其他的組織合作編寫(xiě)了其他的協(xié)議標(biāo)準(zhǔn)，目前這些標(biāo)準(zhǔn)包括：
  • MMUSIC，此草案定義了SDP拓展和ICE拓展支持。
  • AVTCORE，此草案定義了RTP拓展支持。
  • RMCAT，此草案定義了RTP擁塞的控制支持。
  • TRAM，此草案定義了STUN，TURN的拓展支持。
　　在RTCWEB的草案中，列舉了多種用戶場(chǎng)景和其定義，分別列舉了瀏覽器對(duì)瀏覽器之間的用戶場(chǎng)景和瀏覽器對(duì)網(wǎng)關(guān)測(cè)的用戶使用場(chǎng)景：
  • Simple Video Communication Service
  • Simple Video Communication Service, NAT/Firewall that blocks UDP
  • Simple Video Communication Service, Firewall that
  • only allows traffic via a HTTP Proxy
  • Simple Video Communication Service, global service provider
  • Simple Video Communication Service, enterprise aspects
  • Simple Video Communication Service, access change
  • Simple Video Communication Service, QoS
  • Simple Video Communication Service with screen sharing
  • Simple Video Communication Service with file exchange
  • Hockey Game Viewer
  • Multiparty video communication
  • Multiparty on-line game with voice communication
  • Telephony terminal
  • Fedex Call
  • Video conferencing system with central server
　　5、WebRTC媒體協(xié)議棧拓展功能
　　在本章節(jié)中，我們會(huì)分別介紹WebRTC的媒體協(xié)議拓展功能中的幾個(gè)比較關(guān)鍵的概念。首先，我們介紹一下第一個(gè)比較重要的概念RTP的header。
　　在header中，大家需要注意紅色標(biāo)注的部分以及相關(guān)的數(shù)值。例如，Sequence Num檢測(cè)錯(cuò)誤的序列號(hào)，如果檢測(cè)到錯(cuò)誤的或者超出的號(hào)碼，則表示發(fā)生錯(cuò)誤。如果語(yǔ)音播放不順暢或者沒(méi)有連貫性則可能Timestamp時(shí)間戳不同步或者發(fā)生錯(cuò)誤。SSRC來(lái)確認(rèn)發(fā)送到數(shù)據(jù)包數(shù)據(jù)，如果數(shù)據(jù)包丟失的會(huì)，CC 會(huì)累計(jì)加以計(jì)數(shù)。關(guān)于RTP header的具體語(yǔ)法結(jié)構(gòu)，用戶可以查閱rfc來(lái)做進(jìn)一步學(xué)習(xí)。
　　RTCP是另外一個(gè)比較重要的協(xié)議概念。RTCP是針對(duì)每個(gè)RTP 媒體會(huì)話進(jìn)行控制管理的協(xié)議。很多情況下，RTCP端口可以在SDP中設(shè)置（a=），如果不能設(shè)置的話，RTCP使用高于RTP端口的奇數(shù)端口（RTP端口+1）。例如，如果RTP端口是7000，則RTCP使用7001 端口。
　　這里，RTP和RTCP都會(huì)綁定自己的對(duì)應(yīng)的媒體會(huì)話，發(fā)生數(shù)據(jù)的雙方通過(guò)RTCP來(lái)發(fā)送語(yǔ)音質(zhì)量的數(shù)據(jù)。CNMAE中包括了發(fā)送方的數(shù)據(jù)。當(dāng)然，RTCP數(shù)據(jù)包的大小也是有限制的，一般限制在RTP數(shù)據(jù)包的5%。每個(gè)RTP的profile中設(shè)置了RTCP的發(fā)送頻率，發(fā)送時(shí)間以及RTCP發(fā)送的規(guī)則要求。通過(guò)這樣的策略設(shè)置，RTP就可以保證在一定的網(wǎng)絡(luò)帶寬中，不會(huì)過(guò)多耗費(fèi)網(wǎng)絡(luò)資源。
　　RTP使用profile來(lái)進(jìn)行雙方通信的協(xié)商處理，WebRTC使用了拓展的profile來(lái)支持WebRTC的協(xié)商和RTCP的機(jī)制處理。以下是一個(gè)簡(jiǎn)單示例來(lái)說(shuō)明WebRTC的數(shù)據(jù)協(xié)商。
　　在上面的介紹中，在實(shí)際的每個(gè)媒體流中，事實(shí)上RTP和RTCP分別使用了不同的端口來(lái)處理自己本身的業(yè)務(wù)。但是，有時(shí)用戶可能也會(huì)遇到這樣的事情。RTP端口之間的互發(fā)都沒(méi)有問(wèn)題，RTCP端口可能有問(wèn)題。在WebRTC中，為了避免剛才說(shuō)的問(wèn)題，WebRTC使用了多路重用的方式（rtcp mux），它使用了一個(gè)端口實(shí)現(xiàn)了RTP和RTCP的端口共用，減少了端口占用的數(shù)量。當(dāng)然，這樣可能會(huì)導(dǎo)致WebRTC呼叫和SIP呼叫之間的連接問(wèn)題，用戶在實(shí)際使用場(chǎng)景中可能需要排查瀏覽器端設(shè)置或者服務(wù)器端設(shè)置狀態(tài)。例如，在Asterisk 平臺(tái)中，pjsip支持了 rtcp_mux=yes來(lái)支持WebRTC的端口協(xié)商。
　　多路復(fù)用在WebRTC中的影響也是非常明顯的。通常情況下，語(yǔ)音和視頻通過(guò)不同的RTP端口互相發(fā)送。在WebRTC環(huán)境中，WebRTC使用了多路復(fù)用的技術(shù)，把所有的媒體流都通過(guò)一個(gè)RTP端口來(lái)發(fā)送。它可能會(huì)帶來(lái)其他的影響。
　　WebRTC使用單個(gè)RTP端口處理媒體的方式其優(yōu)劣都非常明顯，具體表現(xiàn)在：
  • 降低了ICE Candidates收集數(shù)量
  • 縮短了ICE運(yùn)行時(shí)間
  • 因?yàn)闀?huì)話減少，降低了會(huì)話失敗的幾率
　　可能增加了QoS保障的難度，因?yàn)榻邮辗揭残枰獙?duì)其語(yǔ)音和視頻的SSRC和Payload做不同的處理。
　　接下來(lái)，我們討論一下關(guān)于RTP和NAT在WebRTC中的問(wèn)題。大家知道，RTP并不是直接使用自己RTP本身，它需要UDP來(lái)做傳輸。但是UDP端口都是動(dòng)態(tài)的。為了減少NAT端口映射，在WebRTC中要求使用Symmetric RTP和Symmetric RTCP，這樣比較容易解決NAT問(wèn)題。Symmetric RTP要求收發(fā)都使用同一RTP端口。具體規(guī)范大家可以查閱rfc4961的第三章節(jié)，此章節(jié)對(duì)兩種端口做了定義說(shuō)明。
　　媒體流擁塞也是一個(gè)非常大的問(wèn)題，它直接影響媒體流的質(zhì)量。大家知道，TCP中可以對(duì)擁塞進(jìn)行處理，但是UDP不支持這樣的機(jī)制。如果UDP不支持的話，RTP也就不可能支持擁塞處理機(jī)制。不過(guò)，RTCP可以對(duì)其擁塞進(jìn)行監(jiān)控和反饋，這樣就解決了RTP擁塞機(jī)制的支持問(wèn)題。如果是視頻會(huì)議的呼叫中，其帶寬更是比較敏感的問(wèn)題，在RTCP的數(shù)據(jù)交互中，如果發(fā)生網(wǎng)絡(luò)擁塞，發(fā)送方可以降低帶寬來(lái)避免擁塞。在WebRTC中通過(guò)類似的機(jī)制來(lái)處理：
　　Circuit Breaker, 如果發(fā)生網(wǎng)絡(luò)擁塞時(shí)，RTP應(yīng)該停止發(fā)送數(shù)據(jù)包。具體的設(shè)置策略可以通過(guò)RTP/AVP profile來(lái)實(shí)現(xiàn)。
　　RMCAT方式，其方式借助于TCP的TRFC的機(jī)制。
　　6、WebRTC 信令/傳輸/協(xié)議
　　在本章節(jié)中，我們重點(diǎn)介紹WebRTC的信令，傳輸方式和其使用的幾個(gè)協(xié)議。現(xiàn)在我們簡(jiǎn)單討論一下信令的主要作用：
  • 媒體能力的協(xié)商創(chuàng)建
  • 會(huì)話中的簽權(quán)和認(rèn)證服務(wù)
  • 控制媒體會(huì)話，指示會(huì)話進(jìn)程，修改或結(jié)束會(huì)話過(guò)程
  • 粘結(jié)雙方的創(chuàng)建和同時(shí)修改雙方會(huì)話
　　以上四種作用，第一項(xiàng)是必須的功能，其他都是可選功能。在WebRTC中，簡(jiǎn)單來(lái)說(shuō)，沒(méi)有所謂的標(biāo)準(zhǔn)的信令，瀏覽器和服務(wù)器之間通過(guò)腳本語(yǔ)言來(lái)實(shí)現(xiàn)交互。對(duì)于WebRTC開(kāi)發(fā)人員來(lái)說(shuō)，最小的要求是支持HTTP，支持HTML和WebRTC。其余的完全依賴于開(kāi)發(fā)人員自己的需要。
　　在WebRTC環(huán)境中，因?yàn)闉g覽器都是基于JavaScript運(yùn)行。服務(wù)器端使用何種信令都可以保證用戶之間的兼容性。在以下的示例中，A，B和C服務(wù)器端選擇不同的信令都能保證用戶側(cè)的兼容。
　　但是，一些信令確實(shí)也需要保持一個(gè)標(biāo)準(zhǔn)的互通方式，否則會(huì)出現(xiàn)會(huì)話協(xié)商錯(cuò)誤。這就需要瀏覽器之間的協(xié)商機(jī)制必須是統(tǒng)一的，瀏覽器之間的協(xié)商能夠正常工作，互相理解對(duì)方的媒體能力。因此，無(wú)論服務(wù)器端采用何種信令，對(duì)于終端之間的每個(gè)會(huì)話來(lái)說(shuō)，編碼，媒體，設(shè)置結(jié)果必須標(biāo)準(zhǔn)，ICE 必須能夠互通，SRTP 密鑰必須能夠互通。在信令的傳輸方式中，WebRTC支持三種信令傳輸方式：WebSocket，HTTP和Data Channel。
　　在上面的圖例中，服務(wù)器端使用了WebSocket進(jìn)行信令傳輸。事實(shí)上，WebSocket是以一個(gè)新的HTTP的方式進(jìn)行訪問(wèn)，瀏覽器更新請(qǐng)求，在這個(gè)新的請(qǐng)求中，HTTP連接轉(zhuǎn)成了WebSocket的訪問(wèn)。這里大家注意一下，WebSocket協(xié)議是有IETF定義的，但是WebSocket的API是由W3C定義的。另外，兩個(gè)瀏覽器之間不能直接打開(kāi)一個(gè)WebSocket來(lái)訪問(wèn)對(duì)方。
　　WebRTC的信令也可以通過(guò)HTTP的方式來(lái)進(jìn)行傳輸。每個(gè)瀏覽器通過(guò)XML HTTP請(qǐng)求對(duì)服務(wù)器端發(fā)送數(shù)據(jù)。HTTP使用GET或者POST對(duì)Web服務(wù)器發(fā)送信令消息數(shù)據(jù)。
　　一旦初始的信令通過(guò)WebSocket或者HTTP成功創(chuàng)建以后，接下來(lái)Data通道就成功創(chuàng)建，然后點(diǎn)對(duì)點(diǎn)的媒體交互開(kāi)始啟動(dòng)。Data 通道就會(huì)承載語(yǔ)音和視頻的信令。因?yàn)檎Z(yǔ)音視頻信令都是通過(guò)加密的Data 通道實(shí)現(xiàn)的點(diǎn)對(duì)點(diǎn)通信，所以安全性也大大增強(qiáng)。
　　上面我們提到了HTTP的信令交互問(wèn)題，我們通過(guò)以下示例說(shuō)明如何通過(guò)HTTP Pooling實(shí)現(xiàn)SDP的媒體簡(jiǎn)單交互：
　　下面這個(gè)圖例說(shuō)明了Web服務(wù)器和信令服務(wù)器各自獨(dú)立的服務(wù)器之間的HTTP Pooling的交互：
　　以下圖例演示了不使用Pooling，而使用WebSocket Proxy的處理方式：
　　在WebRTC的信令傳輸方式中，我們也可以使用SIP來(lái)進(jìn)行交互傳輸。這里的SDP媒體協(xié)商使用的rfc3264。瀏覽器終端，SIP終端都可以實(shí)現(xiàn)互通互聯(lián)。
　　對(duì)于SIP語(yǔ)音環(huán)境來(lái)說(shuō)，在運(yùn)行WebRTC時(shí)，WebSocket是一個(gè)新的傳輸方式�，F(xiàn)在很多SIP終端軟電話通過(guò)JavaScript來(lái)實(shí)現(xiàn)。腳本可以下載到瀏覽器端支持了瀏覽器的SIP API，瀏覽器通過(guò)WebSocket打開(kāi)端口實(shí)現(xiàn)SIP注冊(cè)，通過(guò)WSS方式實(shí)現(xiàn)對(duì)WebSocket的加密傳輸。以下示例演示了一個(gè)SIP在WebRTC中的流程機(jī)制（包括SIP終端注冊(cè)和呼叫）：
　　開(kāi)源語(yǔ)音通信解決方案越來(lái)越受到用戶的歡迎。這里我們列出幾個(gè)比較受歡迎的開(kāi)源項(xiàng)目，既包括媒體服務(wù)器和SIP終端產(chǎn)品，大家可以測(cè)試它們的功能。說(shuō)明一下，列表中漏掉了FreeSWITCH。
　　Jingle是XMPP的拓展，客戶端支持JavaScript，它也支持了WebSocket的信令傳輸。因?yàn)镴ingle是XMPP的拓展，這里的信令服務(wù)器還是XPMM服務(wù)器端。
　　通過(guò)我們以上介紹，大概說(shuō)明了各種傳輸方式的過(guò)程，以下圖例匯總了各種方式的利弊：
　　WebRTC中使用了JSEP（Javascript Session Establishment Protocol）來(lái)定義媒體會(huì)話的協(xié)商和DATA通道的協(xié)商。它仍然使用SDP對(duì)象實(shí)體作為會(huì)話描述和Offer/Answer協(xié)商協(xié)議。必須注意到是，JSEP沒(méi)有設(shè)置任何特別的信令模式或者狀態(tài)機(jī)模式，它提供了一種機(jī)制來(lái)創(chuàng)建Offers和Anwers，并且把它們應(yīng)用在會(huì)話中。因此，瀏覽器終端需要自己對(duì)其發(fā)送到數(shù)據(jù)進(jìn)行解析。
　　以下是JSEP的狀態(tài)機(jī)圖例，JSEP提供了六種狀態(tài)機(jī)狀態(tài)，用戶可以到JSEP的規(guī)范中做進(jìn)一步的研究。
　　在WebRTC的SDP拓展中支持了三個(gè)比較新的功能，它們分別是BUNDLE，MSID和任意CNAME。用戶可以到官方網(wǎng)站查閱。
　　下面，我們看一下ICE的處理流程。根據(jù)上面章節(jié)中所介紹的，ICE檢測(cè)需要經(jīng)過(guò)五個(gè)步驟（如果雙方其中一方IP地址發(fā)生改變，需要重新啟動(dòng)ICE，因此也可以算是六個(gè)步驟）。
　　7、WebRTC NAT和ICE
　　WebRTC支持了NAT處理機(jī)制。在WebRTC中，ICE用來(lái)支持NAT處理。我們前面已經(jīng)做過(guò)簡(jiǎn)單介紹，ICE需要STUN和TURN服務(wù)器的支持。關(guān)于NAT和STUN使用，筆者在歷史文檔有過(guò)討論，用戶可以查閱。
　　ICE英文全名是Interactive Connectivity Establishment。RFC5245（更新的RFC6336）對(duì)ICE做了規(guī)定。一般簡(jiǎn)單的定義是：ICE=STUN+TURN+協(xié)商機(jī)制+協(xié)商路徑。以下圖例中表示了ICE的架構(gòu)。
　　以下是一個(gè)Candidate的消息架構(gòu)體，關(guān)于結(jié)構(gòu)體中每個(gè)參數(shù)的含義，請(qǐng)參閱RFC3245的第三部分（Terminology）。
　　前面的章節(jié)中，筆者結(jié)合很多圖例，已經(jīng)簡(jiǎn)單說(shuō)明了ICE創(chuàng)建的六個(gè)步驟。這里再次詳細(xì)強(qiáng)調(diào)一下。ICE所執(zhí)行的六個(gè)步驟分別是：
　　發(fā)現(xiàn)收集申請(qǐng)終端信息。收集到終端可通信的地址，終端申請(qǐng)者的類型（host, Reflexive和Relay candidate）。這四個(gè)地址分別表示了呼叫方內(nèi)網(wǎng)地址，呼叫方公網(wǎng)地址，被呼叫方公網(wǎng)地址和relay地址。
　　以下是一個(gè)SDP的示例，表示了三個(gè)不同的IP地址。
　　根據(jù)優(yōu)先級(jí)對(duì)candidate 進(jìn)行處理，大部分情況下，首先使用Relay candidate
　　解析candidate信息，發(fā)送到對(duì)端candidate
　　對(duì)candidate進(jìn)行配對(duì)處理，保證雙方匹配
　　檢查配對(duì)的candidated的連接性
　　檢查ICE是否可以連接成功，如果成功，則發(fā)送確認(rèn)消息
　　在以上的步驟中，筆者先介紹一下執(zhí)行步驟中一些比較重要的概念和內(nèi)容，然后結(jié)合具體的場(chǎng)景做詳細(xì)分析。在以上的步驟中，STUN服務(wù)器首先需要獲得candidate地址。關(guān)于STUN的具體細(xì)節(jié)，讀者可以在其他權(quán)威網(wǎng)站獲得學(xué)習(xí)資料。
　　除了STUN以為，ICE使用了STURN的拓展服務(wù)器TURN來(lái)獲得一個(gè)relay地址。
　　具體的TURN呼叫流程包括了以下幾個(gè)步驟，開(kāi)始創(chuàng)建連接，創(chuàng)建連接后媒體的互通，定時(shí)刷新超時(shí)設(shè)置和結(jié)束會(huì)話等步驟。
　　STUN和TURN都本身具有自己的method，屬性設(shè)置，安全設(shè)置和錯(cuò)誤碼管理等細(xì)節(jié)規(guī)范，用戶可以參考?xì)v史文檔來(lái)做進(jìn)一步的學(xué)習(xí)，這里不再介紹。
　　通過(guò)STUN和TURN獲得地址以后，接下來(lái)ICE需要開(kāi)始SDP的交換。在SDP交換中，讀者需要注意其安全設(shè)置，例如密碼設(shè)置和幾個(gè)主要的參數(shù)地址：
　　特別說(shuō)明，在以上的圖例中，用戶使用了ice-ufrag和ice-pwd對(duì)STUN進(jìn)行安全認(rèn)證。這兩個(gè)密碼是自動(dòng)生成的任意密碼，用戶名稱最小四個(gè)字符，密碼最小22個(gè)字符。SDP中的幾個(gè)主要參數(shù)用來(lái)實(shí)現(xiàn)對(duì)SDP的協(xié)商交換，我們會(huì)在接下來(lái)的部分做細(xì)節(jié)說(shuō)明。
　　ICE獲得雙方的SDP消息以后，需要對(duì)其進(jìn)行配對(duì)檢查。ICE檢查是否具有同樣的Component ID，通過(guò)配對(duì)以后，結(jié)合呼叫方和被呼叫方生成Foundation配對(duì)。Foundation配對(duì)通過(guò)本地的Foundation和遠(yuǎn)端Foundation結(jié)合生成。大家注意a=candidate的變化，如果本地Foundation是1，收到的遠(yuǎn)端的是2，最后，配對(duì)的Foundation就是1 2。
　　在ICE的檢查中，雙方終端需要通知對(duì)方誰(shuí)是控制方和被控制方。當(dāng)ICE檢查正式開(kāi)始以后，根據(jù)實(shí)際狀態(tài)的不同，每個(gè)candidate陪對(duì)組會(huì)進(jìn)入五種狀態(tài)檢查：
  • Frozen，還沒(méi)有開(kāi)始執(zhí)行檢查
  • Waiting，等待狀態(tài)，還沒(méi)有執(zhí)行
  • In Progress，在處理狀態(tài)
  • Suceeded/Failed，檢查完成，處于成功狀態(tài)，或檢查設(shè)備，處于失敗狀態(tài)。
　　在candidate check完成以后，ICE控制方仍然可以通過(guò)USE-Candidate屬性參數(shù)來(lái)通知ICE被控制方改變candidate pair支持媒體發(fā)送。ICE被控制方回復(fù)USE-Candidate確認(rèn)這個(gè)配對(duì)修改。
　　ICE檢查完成以后，為了保持狀態(tài)存活，雙方需要通過(guò)Keepalives發(fā)送刷新消息保證連接正常，NAT映射不會(huì)超時(shí)等問(wèn)題。這個(gè)時(shí)間周期是15秒。
　　在目前的ICE協(xié)議標(biāo)準(zhǔn)中，目前一個(gè)比較尷尬的問(wèn)題是終端響應(yīng)消息的處理。STURN會(huì)發(fā)送響應(yīng)消息，但是終端不會(huì)處理響應(yīng)消息。這也是目前需要ICE拓展協(xié)議需要進(jìn)一步支持的功能，例如，如果沒(méi)有收到響應(yīng)消息，ICE是否需要重啟；如果收到了響應(yīng)消息，如何進(jìn)行下一步的響應(yīng)處理流程。關(guān)于ICE響應(yīng)消息處理，讀者可以查閱（draft-muthu-behave-consent-freshness-01）。
　　在雙方終端處于運(yùn)行狀態(tài)時(shí)，如果ICE發(fā)現(xiàn)其中一個(gè)candidate的地址發(fā)生改變時(shí)，ICE就會(huì)重新啟動(dòng)ICE，重新配對(duì)。以上是關(guān)于ICE創(chuàng)建，檢查，配對(duì)和時(shí)間刷新的簡(jiǎn)單介紹。為了更加詳細(xì)說(shuō)明ICE的協(xié)商流程，我們通過(guò)一個(gè)SIP/ICE的流程來(lái)說(shuō)明這些具體的步驟：


　　通過(guò)priority oder，結(jié)合兩個(gè)pair check the ICE開(kāi)始測(cè)試。如果雙方測(cè)試成功，則進(jìn)行下一步的信令交互，例如SIP 2 發(fā)送180消息，發(fā)送200 OK消息。如果開(kāi)始發(fā)送到消息和收到的消息不一致，則需要SIP Phone 1 重新發(fā)送Re-INVITE消息，然后進(jìn)行測(cè)試驗(yàn)證，最后收到200 OK消息。
　　ICE 測(cè)試成功以后，則雙方開(kāi)始發(fā)送RTP語(yǔ)音。
　　關(guān)于ICE的支持問(wèn)題，在我們很多常見(jiàn)的環(huán)境中，有的SIP終端可以支持ICE，但是有一些終端可能不支持。用戶可以檢查各種軟電話的ICE配置功能。以下SIP消息中表示終端支持ICE:sip.ice。
　　如果對(duì)端終端不支持ICE的話，終端只能有兩種選擇：1）繼續(xù)連接，但是不使用ICE，ICE支持一個(gè)自動(dòng)檢測(cè)返回的機(jī)制，通知對(duì)端不支持ICE。2）或者繼續(xù)執(zhí)行一個(gè)可選授權(quán)支持的方式使用ICE，根據(jù)RFC5768對(duì)Mandating Support的規(guī)定， SIP終端可以在INVITE請(qǐng)求的Require中添加一個(gè)ice option。
　　另外，用戶可能有時(shí)看到這樣的例子，在終端的SIP INVITE頭中沒(méi)有sip.ice, 但是在SDP中確實(shí)有ICE candidate的信息，這也是互相不兼容導(dǎo)致的結(jié)果，但是最終這是一種不支持ICE的標(biāo)識(shí)。
　　因?yàn)镾IP技術(shù)本身的快速發(fā)展，其實(shí)ICE的版本也在不斷更新。我們簡(jiǎn)單介紹兩個(gè)ICE的“升級(jí)”版本。這里，我稱之為升級(jí)版本僅是對(duì)ICE的一種優(yōu)化，它們并不是在ICE本身的升級(jí)或者更新：
　　ICE-lite主要功能是簡(jiǎn)化了ICE的復(fù)雜性，例如，我們看到的SBC。
　　Trickle ICE主要目的是縮短了ICE的協(xié)商處理時(shí)間，避免重新分配已被轉(zhuǎn)發(fā)的candidate，如果需要?jiǎng)t開(kāi)啟。不像ICE的標(biāo)準(zhǔn)處理流程，標(biāo)準(zhǔn)的ICE需要收集candidate的信息狀態(tài)信息，它則一開(kāi)始就和host candidate檢查連接狀態(tài)，同時(shí)并行處理其他的交換機(jī)制。所以，Trickle ICE相對(duì)較低了處理流程花費(fèi)的時(shí)間。
　　8、WebRTC 安全和隱私
　　安全問(wèn)題和隱私是互聯(lián)網(wǎng)通信中非常重要的話題。在WebRTC中，安全方面的內(nèi)容涉及了很多技術(shù)。當(dāng)然，在瀏覽器使用過(guò)程中，很多廠家提供了一些安全機(jī)制，個(gè)人也應(yīng)該具有一定的安全意識(shí)，這里我們不再花費(fèi)時(shí)間介紹。在WebRTC中，比較重要的兩個(gè)終端資源就是攝像頭和麥克風(fēng)。所以，用戶需要一定的安全設(shè)置或者權(quán)限設(shè)置來(lái)保護(hù)這些媒體資源。WebRTC的使用導(dǎo)致瀏覽器必須支持更多的協(xié)議和更多的服務(wù)器端配置，因此也必然會(huì)帶來(lái)更多的安全風(fēng)險(xiǎn)和被攻擊的可能性。下面，筆者列舉幾個(gè)和安全相關(guān)的建議希望讀者注意：
  • 攻擊者可能通過(guò)WebRTC，通過(guò)JavaScript API接口進(jìn)行攻擊。
  • 瀏覽器用戶可能需要經(jīng)常更新瀏覽器來(lái)防止被攻擊。
  • WebRTC的信令也可能被攻擊，完全取決于使用的信令和端口。例如，使用了WebSocket，SIP的話，攻擊者可能通過(guò)這些接口的安全設(shè)置來(lái)進(jìn)行攻擊。
  • WebRTC的媒體可能被攻擊，例如，是否可能被監(jiān)聽(tīng)，被錄音。
  • SRTP不能對(duì)RTP header進(jìn)行加密，因此兩個(gè)瀏覽器之間的媒體可能仍然不會(huì)得到安全保護(hù)。
　　雖然，SRTP還有一定的局限性，但是SRTP仍然是WebRTC中主要的安全協(xié)議�，F(xiàn)在，我們看一下SRTP的處理流程，它主要經(jīng)過(guò)以下四個(gè)步驟。
　　在這四個(gè)過(guò)程中，前面已經(jīng)介紹過(guò)1，2的步驟，這里，我們重點(diǎn)介紹3，4的步驟。在DTLS的安全認(rèn)證過(guò)程中，它使用的是client/server協(xié)議來(lái)處理。它可以使用CA證書(shū)和自我授權(quán)的證書(shū)來(lái)進(jìn)行證書(shū)驗(yàn)證。因?yàn)镈TLS是一種client/server的工作方式，因此，瀏覽器一端必須是客戶，另外一端必須是服務(wù)器。在WebRTC中，雙方瀏覽器必須選擇其角色。角色選擇通過(guò)SDP消息中設(shè)置（a=setup）， Offer中包含a=setup:actpass, Answer可能包含a=setup:active或者passive。
　　TLS使用的是X.509，是CA簽發(fā)的證書(shū)，但是瀏覽器一般沒(méi)有這些證書(shū)。DTLS-SRTP可以使用public/private key生成的證書(shū)。
　　WebRTC使用場(chǎng)景很多，我們這里比較關(guān)注的是在企業(yè)辦公環(huán)境中的安全問(wèn)題。因此，對(duì)于企業(yè)用戶來(lái)說(shuō)，部署WebRTC需要考慮以下幾個(gè)方面的問(wèn)題：
　　企業(yè)網(wǎng)絡(luò)的防火墻設(shè)置，ACL訪問(wèn)設(shè)置和點(diǎn)對(duì)點(diǎn)的數(shù)據(jù)流動(dòng)問(wèn)題導(dǎo)致的安全隱患
　　瀏覽器之間的錄音錄像，系統(tǒng)日志，企業(yè)安全策略的制定是否影響WebRTC的部署
　　是否可以和目前的企業(yè)網(wǎng)絡(luò)能夠完美融合集成
　　9、WebRTC 使用場(chǎng)景
  • WebRTC的使用場(chǎng)景很多，因?yàn)閃ebRTC是一個(gè)比較新的技術(shù)，因此可能現(xiàn)在仍然有很多新的應(yīng)用場(chǎng)景不斷出現(xiàn)�，F(xiàn)在的使用場(chǎng)景大致分為兩個(gè)部分：一種是通信狀態(tài)下的WebRTC使用場(chǎng)景，另外一種是非通信狀態(tài)下的WebRTC使用場(chǎng)景。通信狀態(tài)下的WebRTC使用場(chǎng)景包括以下幾種：
  • 基于頁(yè)面的電話/視頻會(huì)議
  • 和客戶之間的通信服務(wù)，包括UC融合通信，客戶溝通
  • 企業(yè)融合通信/IPPBX/呼叫中心，支持SIP/HTML實(shí)現(xiàn)和SIP/PSTN的呼叫
  • 分布式的通信方式/公共服務(wù)等
  • 移動(dòng)端的WebRTC支持，WebRTC不僅僅支持桌面瀏覽器，也支持了安卓/IOS原生態(tài)的API接口
  • 簡(jiǎn)單代碼的WebRTC應(yīng)用場(chǎng)景
  • 通過(guò)對(duì)攝像頭和麥克風(fēng)控制實(shí)現(xiàn)其他的操作
  • 遠(yuǎn)程醫(yī)療/家庭護(hù)理
  • 在線客服/現(xiàn)場(chǎng)支持
  • 在線一對(duì)一培訓(xùn)
  • 媒體直播
  • 智能家庭
  • 工業(yè)制造
　　非通信狀態(tài)下的WebRTC應(yīng)用場(chǎng)景包括：
  • 游戲應(yīng)用包括聊天，共享文件等
  • Overlay 網(wǎng)絡(luò)應(yīng)用
  • 機(jī)器學(xué)習(xí)
  • 物聯(lián)網(wǎng)
  • 文件共享
  • 虛擬現(xiàn)實(shí)游戲
　　10、WebRTC當(dāng)前狀態(tài)和發(fā)展趨勢(shì)
　　雖然WebRTC技術(shù)目前應(yīng)用場(chǎng)景很多，技術(shù)發(fā)展也非常迅速。但是，其技術(shù)更新也非�？欤x者需要經(jīng)常查閱官方網(wǎng)站的技術(shù)發(fā)展和趨勢(shì)。
　　幾個(gè)比較重要鏈接如下：
  • https://www.w3.org/TR/webrtc/
  • https://w3c.github.io/webrtc-pc/
  • https://www.w3.org/TR/mediacapture-streams/
　　因?yàn)閃ebRTC依賴于瀏覽器的支持，目前，大部分瀏覽器支持了WebRTC的功能和部分功能，所以讀者要檢查這些瀏覽器的支持狀態(tài)來(lái)開(kāi)發(fā)自己的應(yīng)用：
  • 未來(lái)會(huì)有更多的瀏覽器支持WebRTC。盡管WebRTC應(yīng)用有著非常廣的前景，但是目前仍然面對(duì)很多挑戰(zhàn)：
  • 各種平臺(tái)的兼容性問(wèn)題，特別是視頻編碼的兼容性
  • 標(biāo)準(zhǔn)化部署的問(wèn)題
  • 移動(dòng)平臺(tái)的遷移仍然很少
  • 移動(dòng)端電池壽命的影響
  • 缺乏政府和行業(yè)的標(biāo)準(zhǔn)的支持
　　根據(jù)官方的計(jì)劃和市場(chǎng)的要求，未來(lái)WebRTC技術(shù)仍然需要做的工作很多，幾個(gè)主要的工作需要在不久的將來(lái)來(lái)完成：
　　W3C和IETF規(guī)范和協(xié)議的最終版本形成，因?yàn)檫@些建議很多都是草案，需要形成最終的規(guī)范，未來(lái)需要更多時(shí)間來(lái)完成。
　　瀏覽器需要支持更多的WebRTC功能和最新的版本
　　視頻編碼在WebRTC中廣泛使用，但是需要形成一個(gè)最終的版本
　　在企業(yè)應(yīng)用中，WebRTC的應(yīng)用仍然不是很多，需要更多的應(yīng)用中增加WebRTC的使用比例。
　　11、WebRTC服務(wù)器和開(kāi)源項(xiàng)目示例
　　我們?cè)谇懊娴募夹g(shù)中已經(jīng)提到，WebRTC支持了很多中應(yīng)用場(chǎng)景。其中可能讀者比較感興趣的是視頻會(huì)議的一些解決方案。目前，開(kāi)源的WebRTC服務(wù)器都比較受歡迎：
  • Jitsi
  • Kurento
  • Janus WebRTC 網(wǎng)關(guān)
  • Mediasoup
　　下面的示例是一個(gè)Kurento 和Asterisk集成的示例，通過(guò)Asterisk對(duì)SIP終端實(shí)現(xiàn)管理，這里，Kurento作為WebRTC的媒體服務(wù)器來(lái)實(shí)現(xiàn)視頻會(huì)議的混頻功能。
　　具體的安裝配置，讀者可查閱官方鏈接：
　　https://webrtc.ventures/2017/02/kurento-asterisk-powerful-couple/
　　因?yàn)閃ebRTC的發(fā)展，測(cè)試工具也慢慢增加。網(wǎng)絡(luò)上很多關(guān)于WebRTC的測(cè)試工具。測(cè)試工具的作用也完全不同。今天，筆者為大家介紹一個(gè)關(guān)于WebRTC的壓力測(cè)試工具（Jattack: a WebRTC load testing tool），其論文包括了技術(shù)架構(gòu)，測(cè)試流程，測(cè)試結(jié)果，主要對(duì)系統(tǒng)資源做了測(cè)試分析。
　　具體的測(cè)試方式和測(cè)試結(jié)果，讀者可以查閱參考資料的鏈接，通過(guò)作者論文來(lái)進(jìn)一步的研究。WebRTC的商業(yè)測(cè)試工具也很多，可以檢測(cè)WebRTC的執(zhí)行狀態(tài)，壓力測(cè)試等功能。比較有名的如testRTC，讀者可以購(gòu)買(mǎi)或者試用其demo版本。
　　因?yàn)闉g覽器兼容性的問(wèn)題導(dǎo)致很多WebRTC應(yīng)用不能成功部署，測(cè)試不同瀏覽器的兼容性也是一個(gè)非常頭疼的問(wèn)題。谷歌發(fā)布了對(duì)不同瀏覽器兼容性測(cè)試的工具（KITE），讀者可以做進(jìn)一步的了解。這個(gè)工具測(cè)試也非常方便。它可以測(cè)試不同的項(xiàng)目：


　　讀者可以訪問(wèn)以下鏈接來(lái)訪問(wèn)操作面板：
　　https://kiteboard.herokuapp.com/public?testname=IceConnectionTest
　　12、總結(jié)
　　在WebRTC技術(shù)概要中，筆者從十一個(gè)方面對(duì)WebRTC的技術(shù)做了比較完整全面的介紹。這些章節(jié)包括：背景知識(shí)，媒體的流程，WebRTC組織ITEF/W3C，信令協(xié)議，媒體協(xié)議，NAT/ICE創(chuàng)建流程，安全隱私支持，WebRTC用戶場(chǎng)景，未來(lái)WebRTC技術(shù)方面需要增進(jìn)的部分，同時(shí)也列舉了幾個(gè)在WebRTC部署時(shí)需要面對(duì)的問(wèn)題。最后，筆者為讀者提供了幾個(gè)基于開(kāi)源的解決方案，基于開(kāi)源的WebRTC測(cè)試方案，以及對(duì)WebRTC測(cè)試的工具。
　　筆者盡量在每一個(gè)章節(jié)中把主要的技術(shù)節(jié)點(diǎn)做了相對(duì)比較詳細(xì)全面的介紹，因?yàn)槠�，一些相關(guān)的技術(shù)細(xì)節(jié)需要讀者自己做進(jìn)一步的學(xué)習(xí)，讀者可以根據(jù)這些參考鏈接訪問(wèn)其學(xué)習(xí)資源，也可以通過(guò)rfc規(guī)范和一些草案了解這些技術(shù)的流程。
　　最后，因?yàn)樽髡咚接邢藓蛯W(xué)習(xí)資源受限，另外，考慮到本書(shū)的目標(biāo)讀者是通信行業(yè)或者互聯(lián)網(wǎng)開(kāi)發(fā)的技術(shù)人員，不是針對(duì)WebRTC開(kāi)發(fā)人員的開(kāi)發(fā)資料。因此，本技術(shù)概要雖然相對(duì)比較比較全面，但是沒(méi)有太多關(guān)于WebRTC開(kāi)發(fā)代碼和demo等技術(shù)細(xì)節(jié)。還有，因?yàn)槟壳暗腤ebRTC技術(shù)仍然在不斷完善的過(guò)程中，讀者的解釋或者引用也可能出現(xiàn)錯(cuò)誤或者比較陳舊，很多技術(shù)或觀點(diǎn)也不一定非常準(zhǔn)確及時(shí)，難免有很多錯(cuò)誤的地方，希望讀者諒解。
　　參考資料：
　　https://www.zhihu.com/question/50277029?sort=created
　　https://en.wikipedia.org/wiki/WebRTC_Gateway
　　http://knowledge.santanu.net/what-is-webrtc-current-scenario-and-why-we-should-follow/
　　https://www.rfc-editor.org/rfc/rfc741.txt
　　https://www.avaya.com/blogs/archives/2014/08/understanding-webrtc-media-connections-ice-stun-and-turn.html
　　https://www.rfc-editor.org/info/rfc5245
　　https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-24.txt
　　https://tools.ietf.org/id/draft-ietf-avtcore-cc-feedback-message-03.txt
　　https://www.ietf.org/id/draft-ietf-rmcat-eval-criteria-08.txt
　　https://tools.ietf.org/html/draft-ietf-tram-turnbis-20
　　https://tools.ietf.org/html/draft-muthu-behave-consent-freshness-01
　　https://zh.wikipedia.org/wiki/%E8%A6%86%E7%9B%96%E7%BD%91%E7%BB%9C
　　https://www.researchgate.net/publication/322100933_Jattack_a_WebRTC_load_testing_tool
　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
　　Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
　　Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
　　Asterisk/FreePBX中國(guó)合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
　　關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
　　Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
　　Asterisk freepbx技術(shù)文檔： www.freepbx.org.cn
　　融合通信商業(yè)解決方案，協(xié)同解決方案首選產(chǎn)品：www.hiastar.com
　　Asterisk/FreePBX中國(guó)合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn)，與CTI論壇無(wú)關(guān)。CTI論壇對(duì)文中陳述、觀點(diǎn)判斷保持中立，不對(duì)所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請(qǐng)讀者僅作參考，并請(qǐng)自行承擔(dān)全部責(zé)任。

專題

CTI論壇會(huì)員企業(yè)