Web Real-Time Communication（WebRTC）是最近幾年非常熱門(mén)的一項新的基于瀏覽器的技術(shù)，很多VoIP的廠(chǎng)家和應用集成廠(chǎng)家的解決方案中都逐漸支持了WebRTC技術(shù)。WebRTC技術(shù)通過(guò)對瀏覽器或者移動(dòng)終端應用，結合API接口，實(shí)現了視頻，語(yǔ)音功能。當然，WebRTC受到如此多重視，當然也離不開(kāi)主要的推動(dòng)者Google，微軟，Mozilla等大牌廠(chǎng)家的鼎力支持，以及幾個(gè)著(zhù)名的協(xié)議組織，例如，W3C和IETF的協(xié)助。

　　雖然，網(wǎng)絡(luò )上有很多關(guān)于WebRTC的文章，這些文章通過(guò)不同的角度對WebRTC做了非常詳細的介紹，WebRTC官方網(wǎng)站也發(fā)布了有很多的文檔。但是，很多網(wǎng)上的文章比較零散，討論的角度都不一樣。另外，很多權威的文檔和紙質(zhì)書(shū)基本上都是以英文出版，一些讀者的英文閱讀能力沒(méi)有那么高的話(huà)，可能影響對技術(shù)的消化吸收。為了給中國讀者提供一個(gè)比較全面的完整的關(guān)于WebRTC的技術(shù)以及應用概要，筆者希望通過(guò)一個(gè)完整的篇幅，對WebRTC技術(shù)做一個(gè)比較系統，完整地描述介紹，其內容包括從WebRTC背景知識，媒體流，相關(guān)的協(xié)議棧，NAT處理，安全以及隱身設置，WebRTC當前的問(wèn)題以及未來(lái)的提升，WebRTC用戶(hù)使用場(chǎng)景，和開(kāi)源WebRTC媒體服務(wù)器以及視頻會(huì )議，WebRTC測試工具等知識點(diǎn)，讓普通讀者能夠通過(guò)一篇文章就對WebRTC技術(shù)有一個(gè)非常清晰的思路，為進(jìn)一步學(xué)習WebRTC技術(shù)做一個(gè)有效鋪墊，讀者可以快速進(jìn)入到真正的WebRTC技術(shù)應用開(kāi)發(fā)中。在十一個(gè)章節中，筆者會(huì )根據WebRTC技術(shù)的架構以及相關(guān)的應用做一個(gè)完整的介紹。

　　首先讓我們簡(jiǎn)單了解一下基本的通信背景知識。如果從實(shí)時(shí)通信和語(yǔ)音協(xié)議的發(fā)展來(lái)看，最早的語(yǔ)音通信協(xié)議應該發(fā)生在1977年，人們把實(shí)時(shí)通信技術(shù)通過(guò)Network Voice Protocol（NVP-rfc741）在網(wǎng)絡(luò )上應用，并且演示了其技術(shù)的可用性。在語(yǔ)音發(fā)展過(guò)程中，實(shí)時(shí)通信開(kāi)始也經(jīng)歷了多個(gè)歷史階段，并且結合其他的技術(shù)逐漸實(shí)現了突破。以下是一個(gè)關(guān)于語(yǔ)音技術(shù)的部分階段的發(fā)展進(jìn)程。

　　如下圖示例所示，最初的工作模型也相對比較簡(jiǎn)單，隨著(zhù)技術(shù)的不斷完善和協(xié)議的修改，今天的語(yǔ)音技術(shù)已經(jīng)出現了很大的突破。具體關(guān)于NVP的規范，讀者可以查閱rfc741獲得詳情。

　　在提到實(shí)時(shí)通信技術(shù)或者WebRTC技術(shù)，我們還要簡(jiǎn)單介紹一下實(shí)時(shí)傳輸協(xié)議RTP，此技術(shù)最早在1992年左右開(kāi)始使用，1996年作為一個(gè)標準發(fā)布。目前RTP是VoIP，SIP或者WebRTC的其中一個(gè)部分。

　　除了RTP協(xié)議以外，H323和SIP協(xié)議也是我們進(jìn)入討論WebRTC之前需要介紹的背景知識。H323在1996年有ITU發(fā)布，SIP在1999年由IETF發(fā)布。在最近幾十年的語(yǔ)音視頻領(lǐng)域，這兩種協(xié)議在語(yǔ)音和視頻技術(shù)扮演者非常重要的角色。當然，現在被用戶(hù)和市場(chǎng)認可的是SIP協(xié)議，H323用戶(hù)逐漸變少。

　　WebRTC受到青睞原因很多，我們會(huì )在下面的章節中加以介紹。其主要原因是它的易用性，并且可以借用當前用戶(hù)瀏覽器的其他媒體設備，例如麥克風(fēng)和攝像頭，通過(guò)瀏覽器的API接口直接訪(fǎng)問(wèn)這些網(wǎng)絡(luò )資源，用戶(hù)無(wú)需再安裝下載其他的插件來(lái)獲得對網(wǎng)絡(luò )資源的支持。WebRTC也可以實(shí)現點(diǎn)對點(diǎn)的網(wǎng)絡(luò )互動(dòng)，可以避免遠程服務(wù)器的網(wǎng)絡(luò )訪(fǎng)問(wèn)問(wèn)題。特別是VoLTE網(wǎng)絡(luò )環(huán)境中，語(yǔ)音可以通過(guò)數據通道來(lái)實(shí)現，這樣就會(huì )極大方便終端用戶(hù)的語(yǔ)音視頻通信。另外，現在很多的在線(xiàn)游戲也可以通過(guò)瀏覽器的形式展現游戲場(chǎng)景，用戶(hù)實(shí)現了和同學(xué)，朋友通過(guò)語(yǔ)音，數據和視頻同時(shí)進(jìn)行互動(dòng)交流。

　　現在，我們簡(jiǎn)單介紹一下WebRTC的功能實(shí)現。WebRTC的功能包括以上幾個(gè)核心的模塊和API接口。用戶(hù)瀏覽器通過(guò)和HTML，其他的腳本語(yǔ)言和客戶(hù)端的接口進(jìn)行調用。特別注意，在瀏覽器的RTC功能中，特別包括了傳輸的編碼，回聲處理等功能。其他的媒體數據可以通過(guò)RTC功能和WebRTC實(shí)現通信。

　　接下來(lái)，我們簡(jiǎn)單介紹一下WebRTC的著(zhù)名三角形拓撲示例：

　　以上示例是一個(gè)非常普遍的應用流程示意圖，用戶(hù)可以到官方網(wǎng)站獲得其流程的其他說(shuō)明。特別指出的是，在語(yǔ)音通信環(huán)境中，可能很多用戶(hù)關(guān)心的是如何實(shí)現和SIP，PSTN的網(wǎng)絡(luò )聚合。我們再列舉幾個(gè)和語(yǔ)音環(huán)境相關(guān)的集成方案示例。

　　如果WebRTC實(shí)現對PSTN呼叫的話(huà)，事實(shí)上還是經(jīng)過(guò)SIP/PSTN網(wǎng)關(guān)的轉換，可以支持FXO/FXS或者E1接入方式。

　　如果一些IPPBX（舊版本的IPPBX）沒(méi)有支持WebRTC的話(huà)，或者為了避免WebRTC對接帶來(lái)的問(wèn)題，也可以通過(guò)WebRTC網(wǎng)關(guān)來(lái)對接傳統的SIP/IPPBX，然后實(shí)現IPPBX+WebRTC網(wǎng)關(guān)+瀏覽器WebRTC應用的應用場(chǎng)景。筆者在兩年前使用FreePBX-2.5 結合portSIP WebRTC 網(wǎng)關(guān)實(shí)現的一個(gè)案例。

　　在以上示例中，IPPBX使用的是FreePBX開(kāi)源的企業(yè)IPPBX，PSTN接入可以使用語(yǔ)音板卡或者PSTN語(yǔ)音網(wǎng)關(guān)或者無(wú)線(xiàn)網(wǎng)關(guān)來(lái)實(shí)現，通過(guò)portsip WebRTC網(wǎng)關(guān)實(shí)現和瀏覽器終端的對接。因為客戶(hù)端要求，接入方使用了鼎信通達的無(wú)線(xiàn)網(wǎng)關(guān)實(shí)現，使用了SIM卡直接呼叫。

　　在WebRTC環(huán)境中，每個(gè)終端都不同，它們具有各自的訪(fǎng)問(wèn)方式。以下示例說(shuō)明了各種終端進(jìn)行WebRTC媒體流處理的流程。有的終端可能在家庭網(wǎng)絡(luò )環(huán)境，有的終端可能在公司內網(wǎng)環(huán)境，有的終端可能在咖啡館使用wifi上網(wǎng)。應用服務(wù)器則在公網(wǎng)環(huán)境中。

　　如果在網(wǎng)絡(luò )一般正常的網(wǎng)絡(luò )環(huán)境中，如果沒(méi)有WebRTC的話(huà)，兩個(gè)終端之間的通信只能通過(guò)頁(yè)面服務(wù)器來(lái)做一個(gè)路由處理和交換。但是，如果服務(wù)器和終端之間存在網(wǎng)絡(luò )穩定性問(wèn)題或者距離比較遠的話(huà)，那終端之間的實(shí)時(shí)通信就很難得到保證。

　　如果瀏覽器支持了WebRTC的話(huà)，兩個(gè)終端之間可以不通過(guò)服務(wù)器端進(jìn)行路由，同時(shí)可以解決NAT問(wèn)題，終端之間可以直接實(shí)現點(diǎn)對點(diǎn)通信，這樣就保證了實(shí)時(shí)通信的穩定性。

　　在上面的介紹中，我們討論了WebRTC中的NAT問(wèn)題。關(guān)于NAT問(wèn)題，我們在前面的很多章節中已經(jīng)多次提及，這里不再過(guò)多對NAT做說(shuō)明。今天，我們重點(diǎn)討論WebRTC中的NAT問(wèn)題。WebRTC內置的策略機制（Interactive Connectivity Establishment ）用來(lái)解決NAT問(wèn)題。在點(diǎn)對點(diǎn)的通信中，ICE通過(guò)打洞的方式實(shí)現了點(diǎn)對點(diǎn)的通信。這里，ICE的主要目的是通過(guò)不同服務(wù)器之間的中轉，找到兩個(gè)終端之間連接的最佳路徑。大部分情況下，ICE使用STUN就可以實(shí)現點(diǎn)對點(diǎn)的互通，有時(shí)也需要借助TURN服務(wù)器實(shí)現轉發(fā)來(lái)實(shí)現。ICE對Peers的檢測配對需要經(jīng)過(guò)六個(gè)步驟，rfc5245 對ICE 檢測有如下定義：

　　在第五步時(shí)，需要瀏覽器同時(shí)檢查STUN數據。如下圖所示：

　　當STUN 服務(wù)器查詢(xún)不到兩個(gè)終端的話(huà)，需要借助于TURN 服務(wù)器來(lái)實(shí)現。這里讀者一定要注意，NAT的場(chǎng)景不同，使用的策略可能是不同的，我們這里僅說(shuō)明symmetric的NAT場(chǎng)景。

　　以下是用戶(hù)使用STUN和TURN的一個(gè)簡(jiǎn)單的對比，幫助讀者能夠更加清晰了解這兩個(gè)服務(wù)器的作用和部署成本。關(guān)于ICE的使用和具體參數屬性，筆者將在后續的章節中做非常詳細的介紹，用戶(hù)也可以查閱歷史文檔來(lái)做進(jìn)一步學(xué)習。筆者這里再次提醒，在WebRTC的呼叫過(guò)程中，大部分的呼叫失敗都是因為ICE協(xié)商問(wèn)題，以上六個(gè)步驟是排查時(shí)需要特別注意到地方。

　　WebRTC支持了很多RFC標準，這些組織完成了關(guān)于WebRTC的標準起草，API定義和一些相關(guān)的拓展協(xié)議。其中，三個(gè)組織需要讀者去關(guān)注，它們分別是IETF，W3C和RTCWEB。它們都有自己的官方網(wǎng)站，讀者可以查閱。WebRTC技術(shù)所使用的協(xié)議棧包括以下幾種，讀者可以?xún)H關(guān)注應用層和傳輸層即可。這些協(xié)議在RFC中都有各自的規范定義。比較重要的是ICE規范，關(guān)于ICE的規范，用戶(hù)可以查閱rfc5245。

　　因為融合通信的不斷發(fā)展，WebRTC和SIP互通也變得非常重要，而且在企業(yè)融合通信中，需要接入PSTM或者企業(yè)UC的功能。因此，我們會(huì )花更多時(shí)間在討論WebRTC和SIP之間的關(guān)系及應用中。

　　任何技術(shù)的發(fā)展都離不開(kāi)一些組織的推動(dòng)，這些組織完成了對技術(shù)規范的標準化制定。在上面的章節中，我們提到了RTCWEB工作組，這個(gè)組織對WEBRTC的一些功能正在起草一些新的草案（draft），還沒(méi)有形成正式的rfc規范。這些草案分別是：

　　除了以上草案以外，RTCWEB還和其他的組織合作編寫(xiě)了其他的協(xié)議標準，目前這些標準包括：

　　在RTCWEB的草案中，列舉了多種用戶(hù)場(chǎng)景和其定義，分別列舉了瀏覽器對瀏覽器之間的用戶(hù)場(chǎng)景和瀏覽器對網(wǎng)關(guān)測的用戶(hù)使用場(chǎng)景：

　　在本章節中，我們會(huì )分別介紹WebRTC的媒體協(xié)議拓展功能中的幾個(gè)比較關(guān)鍵的概念。首先，我們介紹一下第一個(gè)比較重要的概念RTP的header。

　　在header中，大家需要注意紅色標注的部分以及相關(guān)的數值。例如，Sequence Num檢測錯誤的序列號，如果檢測到錯誤的或者超出的號碼，則表示發(fā)生錯誤。如果語(yǔ)音播放不順暢或者沒(méi)有連貫性則可能Timestamp時(shí)間戳不同步或者發(fā)生錯誤。SSRC來(lái)確認發(fā)送到數據包數據，如果數據包丟失的會(huì )，CC 會(huì )累計加以計數。關(guān)于RTP header的具體語(yǔ)法結構，用戶(hù)可以查閱rfc來(lái)做進(jìn)一步學(xué)習。

　　RTCP是另外一個(gè)比較重要的協(xié)議概念。RTCP是針對每個(gè)RTP 媒體會(huì )話(huà)進(jìn)行控制管理的協(xié)議。很多情況下，RTCP端口可以在SDP中設置（a=），如果不能設置的話(huà)，RTCP使用高于RTP端口的奇數端口（RTP端口+1）。例如，如果RTP端口是7000，則RTCP使用7001 端口。

　　這里，RTP和RTCP都會(huì )綁定自己的對應的媒體會(huì )話(huà)，發(fā)生數據的雙方通過(guò)RTCP來(lái)發(fā)送語(yǔ)音質(zhì)量的數據。CNMAE中包括了發(fā)送方的數據。當然，RTCP數據包的大小也是有限制的，一般限制在RTP數據包的5%。每個(gè)RTP的profile中設置了RTCP的發(fā)送頻率，發(fā)送時(shí)間以及RTCP發(fā)送的規則要求。通過(guò)這樣的策略設置，RTP就可以保證在一定的網(wǎng)絡(luò )帶寬中，不會(huì )過(guò)多耗費網(wǎng)絡(luò )資源。

　　RTP使用profile來(lái)進(jìn)行雙方通信的協(xié)商處理，WebRTC使用了拓展的profile來(lái)支持WebRTC的協(xié)商和RTCP的機制處理。以下是一個(gè)簡(jiǎn)單示例來(lái)說(shuō)明WebRTC的數據協(xié)商。

　　在上面的介紹中，在實(shí)際的每個(gè)媒體流中，事實(shí)上RTP和RTCP分別使用了不同的端口來(lái)處理自己本身的業(yè)務(wù)。但是，有時(shí)用戶(hù)可能也會(huì )遇到這樣的事情。RTP端口之間的互發(fā)都沒(méi)有問(wèn)題，RTCP端口可能有問(wèn)題。在WebRTC中，為了避免剛才說(shuō)的問(wèn)題，WebRTC使用了多路重用的方式（rtcp mux），它使用了一個(gè)端口實(shí)現了RTP和RTCP的端口共用，減少了端口占用的數量。當然，這樣可能會(huì )導致WebRTC呼叫和SIP呼叫之間的連接問(wèn)題，用戶(hù)在實(shí)際使用場(chǎng)景中可能需要排查瀏覽器端設置或者服務(wù)器端設置狀態(tài)。例如，在A(yíng)sterisk 平臺中，pjsip支持了 rtcp_mux=yes來(lái)支持WebRTC的端口協(xié)商。

　　多路復用在WebRTC中的影響也是非常明顯的。通常情況下，語(yǔ)音和視頻通過(guò)不同的RTP端口互相發(fā)送。在WebRTC環(huán)境中，WebRTC使用了多路復用的技術(shù)，把所有的媒體流都通過(guò)一個(gè)RTP端口來(lái)發(fā)送。它可能會(huì )帶來(lái)其他的影響。

　　WebRTC使用單個(gè)RTP端口處理媒體的方式其優(yōu)劣都非常明顯，具體表現在：

　　可能增加了QoS保障的難度，因為接收方也需要對其語(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端口。具體規范大家可以查閱rfc4961的第三章節，此章節對兩種端口做了定義說(shuō)明。

　　媒體流擁塞也是一個(gè)非常大的問(wèn)題，它直接影響媒體流的質(zhì)量。大家知道，TCP中可以對擁塞進(jìn)行處理，但是UDP不支持這樣的機制。如果UDP不支持的話(huà)，RTP也就不可能支持擁塞處理機制。不過(guò)，RTCP可以對其擁塞進(jìn)行監控和反饋，這樣就解決了RTP擁塞機制的支持問(wèn)題。如果是視頻會(huì )議的呼叫中，其帶寬更是比較敏感的問(wèn)題，在RTCP的數據交互中，如果發(fā)生網(wǎng)絡(luò )擁塞，發(fā)送方可以降低帶寬來(lái)避免擁塞。在WebRTC中通過(guò)類(lèi)似的機制來(lái)處理：

　　Circuit Breaker, 如果發(fā)生網(wǎng)絡(luò )擁塞時(shí)，RTP應該停止發(fā)送數據包。具體的設置策略可以通過(guò)RTP/AVP profile來(lái)實(shí)現。

　　RMCAT方式，其方式借助于TCP的TRFC的機制。

　　在本章節中，我們重點(diǎn)介紹WebRTC的信令，傳輸方式和其使用的幾個(gè)協(xié)議。現在我們簡(jiǎn)單討論一下信令的主要作用：

　　以上四種作用，第一項是必須的功能，其他都是可選功能。在WebRTC中，簡(jiǎn)單來(lái)說(shuō)，沒(méi)有所謂的標準的信令，瀏覽器和服務(wù)器之間通過(guò)腳本語(yǔ)言來(lái)實(shí)現交互。對于WebRTC開(kāi)發(fā)人員來(lái)說(shuō)，最小的要求是支持HTTP，支持HTML和WebRTC。其余的完全依賴(lài)于開(kāi)發(fā)人員自己的需要。

　　在WebRTC環(huán)境中，因為瀏覽器都是基于JavaScript運行。服務(wù)器端使用何種信令都可以保證用戶(hù)之間的兼容性。在以下的示例中，A，B和C服務(wù)器端選擇不同的信令都能保證用戶(hù)側的兼容。

　　但是，一些信令確實(shí)也需要保持一個(gè)標準的互通方式，否則會(huì )出現會(huì )話(huà)協(xié)商錯誤。這就需要瀏覽器之間的協(xié)商機制必須是統一的，瀏覽器之間的協(xié)商能夠正常工作，互相理解對方的媒體能力。因此，無(wú)論服務(wù)器端采用何種信令，對于終端之間的每個(gè)會(huì )話(huà)來(lái)說(shuō)，編碼，媒體，設置結果必須標準，ICE 必須能夠互通，SRTP 密鑰必須能夠互通。在信令的傳輸方式中，WebRTC支持三種信令傳輸方式：WebSocket，HTTP和Data Channel。

　　在上面的圖例中，服務(wù)器端使用了WebSocket進(jìn)行信令傳輸。事實(shí)上，WebSocket是以一個(gè)新的HTTP的方式進(jìn)行訪(fǎng)問(wèn)，瀏覽器更新請求，在這個(gè)新的請求中，HTTP連接轉成了WebSocket的訪(fǎng)問(wèn)。這里大家注意一下，WebSocket協(xié)議是有IETF定義的，但是WebSocket的API是由W3C定義的。另外，兩個(gè)瀏覽器之間不能直接打開(kāi)一個(gè)WebSocket來(lái)訪(fǎng)問(wèn)對方。

　　WebRTC的信令也可以通過(guò)HTTP的方式來(lái)進(jìn)行傳輸。每個(gè)瀏覽器通過(guò)XML HTTP請求對服務(wù)器端發(fā)送數據。HTTP使用GET或者POST對Web服務(wù)器發(fā)送信令消息數據。

　　一旦初始的信令通過(guò)WebSocket或者HTTP成功創(chuàng )建以后，接下來(lái)Data通道就成功創(chuàng )建，然后點(diǎn)對點(diǎn)的媒體交互開(kāi)始啟動(dòng)。Data 通道就會(huì )承載語(yǔ)音和視頻的信令。因為語(yǔ)音視頻信令都是通過(guò)加密的Data 通道實(shí)現的點(diǎn)對點(diǎn)通信，所以安全性也大大增強。

　　上面我們提到了HTTP的信令交互問(wèn)題，我們通過(guò)以下示例說(shuō)明如何通過(guò)HTTP Pooling實(shí)現SDP的媒體簡(jiǎn)單交互：

　　下面這個(gè)圖例說(shuō)明了Web服務(wù)器和信令服務(wù)器各自獨立的服務(wù)器之間的HTTP Pooling的交互：

　　以下圖例演示了不使用Pooling，而使用WebSocket Proxy的處理方式：

　　在WebRTC的信令傳輸方式中，我們也可以使用SIP來(lái)進(jìn)行交互傳輸。這里的SDP媒體協(xié)商使用的rfc3264。瀏覽器終端，SIP終端都可以實(shí)現互通互聯(lián)。

　　對于SIP語(yǔ)音環(huán)境來(lái)說(shuō)，在運行WebRTC時(shí)，WebSocket是一個(gè)新的傳輸方式。現在很多SIP終端軟電話(huà)通過(guò)JavaScript來(lái)實(shí)現。腳本可以下載到瀏覽器端支持了瀏覽器的SIP API，瀏覽器通過(guò)WebSocket打開(kāi)端口實(shí)現SIP注冊，通過(guò)WSS方式實(shí)現對WebSocket的加密傳輸。以下示例演示了一個(gè)SIP在WebRTC中的流程機制（包括SIP終端注冊和呼叫）：

　　開(kāi)源語(yǔ)音通信解決方案越來(lái)越受到用戶(hù)的歡迎。這里我們列出幾個(gè)比較受歡迎的開(kāi)源項目，既包括媒體服務(wù)器和SIP終端產(chǎn)品，大家可以測試它們的功能。說(shuō)明一下，列表中漏掉了FreeSWITCH。

　　Jingle是XMPP的拓展，客戶(hù)端支持JavaScript，它也支持了WebSocket的信令傳輸。因為Jingle是XMPP的拓展，這里的信令服務(wù)器還是XPMM服務(wù)器端。

　　通過(guò)我們以上介紹，大概說(shuō)明了各種傳輸方式的過(guò)程，以下圖例匯總了各種方式的利弊：

　　WebRTC中使用了JSEP（Javascript Session Establishment Protocol）來(lái)定義媒體會(huì )話(huà)的協(xié)商和DATA通道的協(xié)商。它仍然使用SDP對象實(shí)體作為會(huì )話(huà)描述和Offer/Answer協(xié)商協(xié)議。必須注意到是，JSEP沒(méi)有設置任何特別的信令模式或者狀態(tài)機模式，它提供了一種機制來(lái)創(chuàng )建Offers和Anwers，并且把它們應用在會(huì )話(huà)中。因此，瀏覽器終端需要自己對其發(fā)送到數據進(jìn)行解析。

　　以下是JSEP的狀態(tài)機圖例，JSEP提供了六種狀態(tài)機狀態(tài)，用戶(hù)可以到JSEP的規范中做進(jìn)一步的研究。

　　在WebRTC的SDP拓展中支持了三個(gè)比較新的功能，它們分別是BUNDLE，MSID和任意CNAME。用戶(hù)可以到官方網(wǎng)站查閱。

　　下面，我們看一下ICE的處理流程。根據上面章節中所介紹的，ICE檢測需要經(jīng)過(guò)五個(gè)步驟（如果雙方其中一方IP地址發(fā)生改變，需要重新啟動(dòng)ICE，因此也可以算是六個(gè)步驟）。

　　WebRTC支持了NAT處理機制。在WebRTC中，ICE用來(lái)支持NAT處理。我們前面已經(jīng)做過(guò)簡(jiǎn)單介紹，ICE需要STUN和TURN服務(wù)器的支持。關(guān)于NAT和STUN使用，筆者在歷史文檔有過(guò)討論，用戶(hù)可以查閱。

　　ICE英文全名是Interactive Connectivity Establishment。RFC5245（更新的RFC6336）對ICE做了規定。一般簡(jiǎn)單的定義是：ICE=STUN+TURN+協(xié)商機制+協(xié)商路徑。以下圖例中表示了ICE的架構。

　　以下是一個(gè)Candidate的消息架構體，關(guān)于結構體中每個(gè)參數的含義，請參閱RFC3245的第三部分（Terminology）。

　　前面的章節中，筆者結合很多圖例，已經(jīng)簡(jiǎn)單說(shuō)明了ICE創(chuàng )建的六個(gè)步驟。這里再次詳細強調一下。ICE所執行的六個(gè)步驟分別是：

　　發(fā)現收集申請終端信息。收集到終端可通信的地址，終端申請者的類(lèi)型（host, Reflexive和Relay candidate）。這四個(gè)地址分別表示了呼叫方內網(wǎng)地址，呼叫方公網(wǎng)地址，被呼叫方公網(wǎng)地址和relay地址。

　　以下是一個(gè)SDP的示例，表示了三個(gè)不同的IP地址。

　　根據優(yōu)先級對candidate 進(jìn)行處理，大部分情況下，首先使用Relay candidate

　　解析candidate信息，發(fā)送到對端candidate

　　對candidate進(jìn)行配對處理，保證雙方匹配

　　檢查配對的candidated的連接性

　　檢查ICE是否可以連接成功，如果成功，則發(fā)送確認消息

　　在以上的步驟中，筆者先介紹一下執行步驟中一些比較重要的概念和內容，然后結合具體的場(chǎng)景做詳細分析。在以上的步驟中，STUN服務(wù)器首先需要獲得candidate地址。關(guān)于STUN的具體細節，讀者可以在其他權威網(wǎng)站獲得學(xué)習資料。

　　除了STUN以為，ICE使用了STURN的拓展服務(wù)器TURN來(lái)獲得一個(gè)relay地址。

　　具體的TURN呼叫流程包括了以下幾個(gè)步驟，開(kāi)始創(chuàng )建連接，創(chuàng )建連接后媒體的互通，定時(shí)刷新超時(shí)設置和結束會(huì )話(huà)等步驟。

　　STUN和TURN都本身具有自己的method，屬性設置，安全設置和錯誤碼管理等細節規范，用戶(hù)可以參考歷史文檔來(lái)做進(jìn)一步的學(xué)習，這里不再介紹。

　　通過(guò)STUN和TURN獲得地址以后，接下來(lái)ICE需要開(kāi)始SDP的交換。在SDP交換中，讀者需要注意其安全設置，例如密碼設置和幾個(gè)主要的參數地址：

　　特別說(shuō)明，在以上的圖例中，用戶(hù)使用了ice-ufrag和ice-pwd對STUN進(jìn)行安全認證。這兩個(gè)密碼是自動(dòng)生成的任意密碼，用戶(hù)名稱(chēng)最小四個(gè)字符，密碼最小22個(gè)字符。SDP中的幾個(gè)主要參數用來(lái)實(shí)現對SDP的協(xié)商交換，我們會(huì )在接下來(lái)的部分做細節說(shuō)明。

　　ICE獲得雙方的SDP消息以后，需要對其進(jìn)行配對檢查。ICE檢查是否具有同樣的Component ID，通過(guò)配對以后，結合呼叫方和被呼叫方生成Foundation配對。Foundation配對通過(guò)本地的Foundation和遠端Foundation結合生成。大家注意a=candidate的變化，如果本地Foundation是1，收到的遠端的是2，最后，配對的Foundation就是1 2。

　　在ICE的檢查中，雙方終端需要通知對方誰(shuí)是控制方和被控制方。當ICE檢查正式開(kāi)始以后，根據實(shí)際狀態(tài)的不同，每個(gè)candidate陪對組會(huì )進(jìn)入五種狀態(tài)檢查：

　　在candidate check完成以后，ICE控制方仍然可以通過(guò)USE-Candidate屬性參數來(lái)通知ICE被控制方改變candidate pair支持媒體發(fā)送。ICE被控制方回復USE-Candidate確認這個(gè)配對修改。

　　ICE檢查完成以后，為了保持狀態(tài)存活，雙方需要通過(guò)Keepalives發(fā)送刷新消息保證連接正常，NAT映射不會(huì )超時(shí)等問(wèn)題。這個(gè)時(shí)間周期是15秒。

　　在目前的ICE協(xié)議標準中，目前一個(gè)比較尷尬的問(wèn)題是終端響應消息的處理。STURN會(huì )發(fā)送響應消息，但是終端不會(huì )處理響應消息。這也是目前需要ICE拓展協(xié)議需要進(jìn)一步支持的功能，例如，如果沒(méi)有收到響應消息，ICE是否需要重啟；如果收到了響應消息，如何進(jìn)行下一步的響應處理流程。關(guān)于ICE響應消息處理，讀者可以查閱（draft-muthu-behave-consent-freshness-01）。

　　在雙方終端處于運行狀態(tài)時(shí)，如果ICE發(fā)現其中一個(gè)candidate的地址發(fā)生改變時(shí)，ICE就會(huì )重新啟動(dòng)ICE，重新配對。以上是關(guān)于ICE創(chuàng )建，檢查，配對和時(shí)間刷新的簡(jiǎn)單介紹。為了更加詳細說(shuō)明ICE的協(xié)商流程，我們通過(guò)一個(gè)SIP/ICE的流程來(lái)說(shuō)明這些具體的步驟：

　　通過(guò)priority oder，結合兩個(gè)pair check the ICE開(kāi)始測試。如果雙方測試成功，則進(jìn)行下一步的信令交互，例如SIP 2 發(fā)送180消息，發(fā)送200 OK消息。如果開(kāi)始發(fā)送到消息和收到的消息不一致，則需要SIP Phone 1 重新發(fā)送Re-INVITE消息，然后進(jìn)行測試驗證，最后收到200 OK消息。

　　ICE 測試成功以后，則雙方開(kāi)始發(fā)送RTP語(yǔ)音。

　　關(guān)于ICE的支持問(wèn)題，在我們很多常見(jiàn)的環(huán)境中，有的SIP終端可以支持ICE，但是有一些終端可能不支持。用戶(hù)可以檢查各種軟電話(huà)的ICE配置功能。以下SIP消息中表示終端支持ICE:sip.ice。

　　如果對端終端不支持ICE的話(huà)，終端只能有兩種選擇：1）繼續連接，但是不使用ICE，ICE支持一個(gè)自動(dòng)檢測返回的機制，通知對端不支持ICE。2）或者繼續執行一個(gè)可選授權支持的方式使用ICE，根據RFC5768對Mandating Support的規定， SIP終端可以在INVITE請求的Require中添加一個(gè)ice option。

　　另外，用戶(hù)可能有時(shí)看到這樣的例子，在終端的SIP INVITE頭中沒(méi)有sip.ice, 但是在SDP中確實(shí)有ICE candidate的信息，這也是互相不兼容導致的結果，但是最終這是一種不支持ICE的標識。

　　因為SIP技術(shù)本身的快速發(fā)展，其實(shí)ICE的版本也在不斷更新。我們簡(jiǎn)單介紹兩個(gè)ICE的“升級”版本。這里，我稱(chēng)之為升級版本僅是對ICE的一種優(yōu)化，它們并不是在ICE本身的升級或者更新：

　　ICE-lite主要功能是簡(jiǎn)化了ICE的復雜性，例如，我們看到的SBC。

　　Trickle ICE主要目的是縮短了ICE的協(xié)商處理時(shí)間，避免重新分配已被轉發(fā)的candidate，如果需要則開(kāi)啟。不像ICE的標準處理流程，標準的ICE需要收集candidate的信息狀態(tài)信息，它則一開(kāi)始就和host candidate檢查連接狀態(tài)，同時(shí)并行處理其他的交換機制。所以，Trickle ICE相對較低了處理流程花費的時(shí)間。

　　安全問(wèn)題和隱私是互聯(lián)網(wǎng)通信中非常重要的話(huà)題。在WebRTC中，安全方面的內容涉及了很多技術(shù)。當然，在瀏覽器使用過(guò)程中，很多廠(chǎng)家提供了一些安全機制，個(gè)人也應該具有一定的安全意識，這里我們不再花費時(shí)間介紹。在WebRTC中，比較重要的兩個(gè)終端資源就是攝像頭和麥克風(fēng)。所以，用戶(hù)需要一定的安全設置或者權限設置來(lái)保護這些媒體資源。WebRTC的使用導致瀏覽器必須支持更多的協(xié)議和更多的服務(wù)器端配置，因此也必然會(huì )帶來(lái)更多的安全風(fēng)險和被攻擊的可能性。下面，筆者列舉幾個(gè)和安全相關(guān)的建議希望讀者注意：

　　雖然，SRTP還有一定的局限性，但是SRTP仍然是WebRTC中主要的安全協(xié)議。現在，我們看一下SRTP的處理流程，它主要經(jīng)過(guò)以下四個(gè)步驟。

　　在這四個(gè)過(guò)程中，前面已經(jīng)介紹過(guò)1，2的步驟，這里，我們重點(diǎn)介紹3，4的步驟。在DTLS的安全認證過(guò)程中，它使用的是client/server協(xié)議來(lái)處理。它可以使用CA證書(shū)和自我授權的證書(shū)來(lái)進(jìn)行證書(shū)驗證。因為DTLS是一種client/server的工作方式，因此，瀏覽器一端必須是客戶(hù)，另外一端必須是服務(wù)器。在WebRTC中，雙方瀏覽器必須選擇其角色。角色選擇通過(guò)SDP消息中設置（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)題。因此，對于企業(yè)用戶(hù)來(lái)說(shuō)，部署WebRTC需要考慮以下幾個(gè)方面的問(wèn)題：

　　企業(yè)網(wǎng)絡(luò )的防火墻設置，ACL訪(fǎng)問(wèn)設置和點(diǎn)對點(diǎn)的數據流動(dòng)問(wèn)題導致的安全隱患

　　瀏覽器之間的錄音錄像，系統日志，企業(yè)安全策略的制定是否影響WebRTC的部署

　　是否可以和目前的企業(yè)網(wǎng)絡(luò )能夠完美融合集成

　　非通信狀態(tài)下的WebRTC應用場(chǎng)景包括：

　　雖然WebRTC技術(shù)目前應用場(chǎng)景很多，技術(shù)發(fā)展也非常迅速。但是，其技術(shù)更新也非常快，讀者需要經(jīng)常查閱官方網(wǎng)站的技術(shù)發(fā)展和趨勢。

　　幾個(gè)比較重要鏈接如下：

　　因為WebRTC依賴(lài)于瀏覽器的支持，目前，大部分瀏覽器支持了WebRTC的功能和部分功能，所以讀者要檢查這些瀏覽器的支持狀態(tài)來(lái)開(kāi)發(fā)自己的應用：

　　根據官方的計劃和市場(chǎng)的要求，未來(lái)WebRTC技術(shù)仍然需要做的工作很多，幾個(gè)主要的工作需要在不久的將來(lái)來(lái)完成：

　　W3C和IETF規范和協(xié)議的最終版本形成，因為這些建議很多都是草案，需要形成最終的規范，未來(lái)需要更多時(shí)間來(lái)完成。

　　瀏覽器需要支持更多的WebRTC功能和最新的版本

　　視頻編碼在WebRTC中廣泛使用，但是需要形成一個(gè)最終的版本

　　在企業(yè)應用中，WebRTC的應用仍然不是很多，需要更多的應用中增加WebRTC的使用比例。

　　我們在前面的技術(shù)中已經(jīng)提到，WebRTC支持了很多中應用場(chǎng)景。其中可能讀者比較感興趣的是視頻會(huì )議的一些解決方案。目前，開(kāi)源的WebRTC服務(wù)器都比較受歡迎：

　　下面的示例是一個(gè)Kurento 和Asterisk集成的示例，通過(guò)Asterisk對SIP終端實(shí)現管理，這里，Kurento作為WebRTC的媒體服務(wù)器來(lái)實(shí)現視頻會(huì )議的混頻功能。

　　具體的安裝配置，讀者可查閱官方鏈接：

　　https://webrtc.ventures/2017/02/kurento-asterisk-powerful-couple/

　　因為WebRTC的發(fā)展，測試工具也慢慢增加。網(wǎng)絡(luò )上很多關(guān)于WebRTC的測試工具。測試工具的作用也完全不同。今天，筆者為大家介紹一個(gè)關(guān)于WebRTC的壓力測試工具（Jattack: a WebRTC load testing tool），其論文包括了技術(shù)架構，測試流程，測試結果，主要對系統資源做了測試分析。

　　具體的測試方式和測試結果，讀者可以查閱參考資料的鏈接，通過(guò)作者論文來(lái)進(jìn)一步的研究。WebRTC的商業(yè)測試工具也很多，可以檢測WebRTC的執行狀態(tài)，壓力測試等功能。比較有名的如testRTC，讀者可以購買(mǎi)或者試用其demo版本。

　　因為瀏覽器兼容性的問(wèn)題導致很多WebRTC應用不能成功部署，測試不同瀏覽器的兼容性也是一個(gè)非常頭疼的問(wèn)題。谷歌發(fā)布了對不同瀏覽器兼容性測試的工具（KITE），讀者可以做進(jìn)一步的了解。這個(gè)工具測試也非常方便。它可以測試不同的項目：

　　讀者可以訪(fǎng)問(wèn)以下鏈接來(lái)訪(fǎng)問(wèn)操作面板：

　　https://kiteboard.herokuapp.com/public?testname=IceConnectionTest

　　在WebRTC技術(shù)概要中，筆者從十一個(gè)方面對WebRTC的技術(shù)做了比較完整全面的介紹。這些章節包括：背景知識，媒體的流程，WebRTC組織ITEF/W3C，信令協(xié)議，媒體協(xié)議，NAT/ICE創(chuàng )建流程，安全隱私支持，WebRTC用戶(hù)場(chǎng)景，未來(lái)WebRTC技術(shù)方面需要增進(jìn)的部分，同時(shí)也列舉了幾個(gè)在WebRTC部署時(shí)需要面對的問(wèn)題。最后，筆者為讀者提供了幾個(gè)基于開(kāi)源的解決方案，基于開(kāi)源的WebRTC測試方案，以及對WebRTC測試的工具。

　　筆者盡量在每一個(gè)章節中把主要的技術(shù)節點(diǎn)做了相對比較詳細全面的介紹，因為篇幅所限，一些相關(guān)的技術(shù)細節需要讀者自己做進(jìn)一步的學(xué)習，讀者可以根據這些參考鏈接訪(fǎng)問(wèn)其學(xué)習資源，也可以通過(guò)rfc規范和一些草案了解這些技術(shù)的流程。

　　最后，因為作者水平有限和學(xué)習資源受限，另外，考慮到本書(shū)的目標讀者是通信行業(yè)或者互聯(lián)網(wǎng)開(kāi)發(fā)的技術(shù)人員，不是針對WebRTC開(kāi)發(fā)人員的開(kāi)發(fā)資料。因此，本技術(shù)概要雖然相對比較比較全面，但是沒(méi)有太多關(guān)于WebRTC開(kāi)發(fā)代碼和demo等技術(shù)細節。還有，因為目前的WebRTC技術(shù)仍然在不斷完善的過(guò)程中，讀者的解釋或者引用也可能出現錯誤或者比較陳舊，很多技術(shù)或觀(guān)點(diǎn)也不一定非常準確及時(shí)，難免有很多錯誤的地方，希望讀者諒解。

　　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)注微信公眾號：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中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817

　　關(guān)注微信公眾號：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中國合作伙伴，官方qq技術(shù)分享群（3000千人）：589995817