杨幂胸视频,很多美女视频

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

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

　　1、WebRTC的技術背景介紹

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

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

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

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

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

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

　　WebRTC受到市場的認可有很多原因。它主要包括以下幾個方面的原因：

平臺和設備的獨立。開發(fā)人員可以通過支持WebRTC的瀏覽器開發(fā)基于WebRTC的各種應用，無需擔心終端和操作系統(tǒng)層面的兼容性問題。另外，WebRTC也提供了標準的API（W3C）和其標準的協(xié)議支持（IETF）避免了平臺兼容性的問題。
語音和視頻的安全處理， WebRTC通過SRTP對語音和視頻進行加密處理。用戶使用瀏覽器登錄訪問語音和視頻需要比較安全的設置要求，滿足了用戶場景的安全要求（例如，在無安全保障的wifi環(huán)境下的語音和視頻），其他人不能對其進行監(jiān)聽。
支持高級語言和視頻處理，WebRTC支持了最新的編碼，語音支持了Opus，視頻支持了VP8。內置的編碼排除了其他第三方下載的安全隱患，同時能夠支持網絡環(huán)境的調整，實現(xiàn)了比較好的語音或視頻質量。
支持可靠性傳輸創(chuàng)建，WebRTC提供了可靠性傳輸方式，包括了在NAT環(huán)境下仍然可以實現(xiàn)傳輸?shù)姆€(wěn)定性。
支持多媒體流處理，WebRTC提供了多媒體和多資源的聚和，提供了RTP和SDP的拓展。
支持不同網絡環(huán)境調節(jié)，因為WebRTC在網絡平臺執(zhí)行，所以對網絡環(huán)境和帶寬非常敏感。它可以自己檢測，調整網絡環(huán)境和帶寬需求，避免網絡擁塞。它通過RTCP和SAVPF來保障此功能。
和VoIP語音視頻有比較好的兼容性，WebRTC實現(xiàn)了和其他媒體的兼容性操作，包括了SIP，Jingle和XMPP對接。同時，如果需要和傳統(tǒng)的其他協(xié)議對接的話，可以通過WebRTC 網關來實現(xiàn)兼容性的流暢性，保證和傳統(tǒng)協(xié)議的兼容性。

　　使用WebRTC對開發(fā)人員和用戶有以下幾個方面的好處：

開發(fā)人員可以無需擔心平臺的兼容性，實現(xiàn)無縫集成。
開發(fā)人員可以使用簡單的API接口就可以實現(xiàn)應用開發(fā)。
開發(fā)人員無需擔心NAT帶來的問題。
開發(fā)人員可以使用比較高級的編碼資源，無需承擔商業(yè)許可證費用。
用戶無需安裝即可使用。
用戶所有通信都是加密的。
用戶可以實現(xiàn)可靠性傳輸。
用戶可以使用高清語音和視頻。
用戶可以選擇更多的實時通信手段。

　　接下來，我們簡單介紹一下WebRTC的著名三角形拓撲示例：

　　以上示例是一個非常普遍的應用流程示意圖，用戶可以到官方網站獲得其流程的其他說明。特別指出的是，在語音通信環(huán)境中，可能很多用戶關心的是如何實現(xiàn)和SIP，PSTN的網絡聚合。我們再列舉幾個和語音環(huán)境相關的集成方案示例。

　　如果WebRTC實現(xiàn)對PSTN呼叫的話，事實上還是經過SIP/PSTN網關的轉換，可以支持FXO/FXS或者E1接入方式。

　　如果一些IPPBX（舊版本的IPPBX）沒有支持WebRTC的話，或者為了避免WebRTC對接帶來的問題，也可以通過WebRTC網關來對接傳統(tǒng)的SIP/IPPBX，然后實現(xiàn)IPPBX+WebRTC網關+瀏覽器WebRTC應用的應用場景。筆者在兩年前使用FreePBX-2.5 結合portSIP WebRTC 網關實現(xiàn)的一個案例。

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

　　2、WebRTC 媒體流處理

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

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

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

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

Sort the candidate pairs in priority order.
Send checks on each candidate pair in priority order.
Acknowledge checks received from the other agent.

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

　　STUN 服務器的查詢過程如下：

　　當STUN 服務器查詢不到兩個終端的話，需要借助于TURN 服務器來實現(xiàn)。這里讀者一定要注意，NAT的場景不同，使用的策略可能是不同的，我們這里僅說明symmetric的NAT場景。

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

　　3、WebRTC 相關協(xié)議

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

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

　　4、WebRTC相關草案

　　任何技術的發(fā)展都離不開一些組織的推動，這些組織完成了對技術規(guī)范的標準化制定。在上面的章節(jié)中，我們提到了RTCWEB工作組，這個組織對WEBRTC的一些功能正在起草一些新的草案（draft），還沒有形成正式的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é)議標準，目前這些標準包括：

MMUSIC，此草案定義了SDP拓展和ICE拓展支持。
AVTCORE，此草案定義了RTP拓展支持。
RMCAT，此草案定義了RTP擁塞的控制支持。
TRAM，此草案定義了STUN，TURN的拓展支持。

　　在RTCWEB的草案中，列舉了多種用戶場景和其定義，分別列舉了瀏覽器對瀏覽器之間的用戶場景和瀏覽器對網關測的用戶使用場景：

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é)中，我們會分別介紹WebRTC的媒體協(xié)議拓展功能中的幾個比較關鍵的概念。首先，我們介紹一下第一個比較重要的概念RTP的header。

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

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

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

　　RTP使用profile來進行雙方通信的協(xié)商處理，WebRTC使用了拓展的profile來支持WebRTC的協(xié)商和RTCP的機制處理。以下是一個簡單示例來說明WebRTC的數(shù)據(jù)協(xié)商。

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

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

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

降低了ICE Candidates收集數(shù)量
縮短了ICE運行時間
因為會話減少，降低了會話失敗的幾率

　　可能增加了QoS保障的難度，因為接收方也需要對其語音和視頻的SSRC和Payload做不同的處理。

　　接下來，我們討論一下關于RTP和NAT在WebRTC中的問題。大家知道，RTP并不是直接使用自己RTP本身，它需要UDP來做傳輸。但是UDP端口都是動態(tài)的。為了減少NAT端口映射，在WebRTC中要求使用Symmetric RTP和Symmetric RTCP，這樣比較容易解決NAT問題。Symmetric RTP要求收發(fā)都使用同一RTP端口。具體規(guī)范大家可以查閱rfc4961的第三章節(jié)，此章節(jié)對兩種端口做了定義說明。

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

　　Circuit Breaker, 如果發(fā)生網絡擁塞時，RTP應該停止發(fā)送數(shù)據(jù)包。具體的設置策略可以通過RTP/AVP profile來實現(xiàn)。

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

　　6、WebRTC 信令/傳輸/協(xié)議

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

媒體能力的協(xié)商創(chuàng)建
會話中的簽權和認證服務
控制媒體會話，指示會話進程，修改或結束會話過程
粘結雙方的創(chuàng)建和同時修改雙方會話

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

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

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

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

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

　　一旦初始的信令通過WebSocket或者HTTP成功創(chuàng)建以后，接下來Data通道就成功創(chuàng)建，然后點對點的媒體交互開始啟動。Data 通道就會承載語音和視頻的信令。因為語音視頻信令都是通過加密的Data 通道實現(xiàn)的點對點通信，所以安全性也大大增強。

　　上面我們提到了HTTP的信令交互問題，我們通過以下示例說明如何通過HTTP Pooling實現(xiàn)SDP的媒體簡單交互：

　　下面這個圖例說明了Web服務器和信令服務器各自獨立的服務器之間的HTTP Pooling的交互：

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

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

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

　　開源語音通信解決方案越來越受到用戶的歡迎。這里我們列出幾個比較受歡迎的開源項目，既包括媒體服務器和SIP終端產品，大家可以測試它們的功能。說明一下，列表中漏掉了FreeSWITCH。

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

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

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

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

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

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

　　7、WebRTC NAT和ICE

　　WebRTC支持了NAT處理機制。在WebRTC中，ICE用來支持NAT處理。我們前面已經做過簡單介紹，ICE需要STUN和TURN服務器的支持。關于NAT和STUN使用，筆者在歷史文檔有過討論，用戶可以查閱。

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

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

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

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

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

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

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

　　對candidate進行配對處理，保證雙方匹配

　　檢查配對的candidated的連接性

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

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

　　除了STUN以為，ICE使用了STURN的拓展服務器TURN來獲得一個relay地址。

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

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

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

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

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

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

Frozen，還沒有開始執(zhí)行檢查
Waiting，等待狀態(tài)，還沒有執(zhí)行
In Progress，在處理狀態(tài)
Suceeded/Failed，檢查完成，處于成功狀態(tài)，或檢查設備，處于失敗狀態(tài)。

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

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

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

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

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

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

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

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

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

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

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

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

　　8、WebRTC 安全和隱私

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

攻擊者可能通過WebRTC，通過JavaScript API接口進行攻擊。
瀏覽器用戶可能需要經常更新瀏覽器來防止被攻擊。
WebRTC的信令也可能被攻擊，完全取決于使用的信令和端口。例如，使用了WebSocket，SIP的話，攻擊者可能通過這些接口的安全設置來進行攻擊。
WebRTC的媒體可能被攻擊，例如，是否可能被監(jiān)聽，被錄音。
SRTP不能對RTP header進行加密，因此兩個瀏覽器之間的媒體可能仍然不會得到安全保護。

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

　　在這四個過程中，前面已經介紹過1，2的步驟，這里，我們重點介紹3，4的步驟。在DTLS的安全認證過程中，它使用的是client/server協(xié)議來處理。它可以使用CA證書和自我授權的證書來進行證書驗證。因為DTLS是一種client/server的工作方式，因此，瀏覽器一端必須是客戶，另外一端必須是服務器。在WebRTC中，雙方瀏覽器必須選擇其角色。角色選擇通過SDP消息中設置（a=setup）， Offer中包含a=setup:actpass, Answer可能包含a=setup:active或者passive。

　　TLS使用的是X.509，是CA簽發(fā)的證書，但是瀏覽器一般沒有這些證書。DTLS-SRTP可以使用public/private key生成的證書。

　　WebRTC使用場景很多，我們這里比較關注的是在企業(yè)辦公環(huán)境中的安全問題。因此，對于企業(yè)用戶來說，部署WebRTC需要考慮以下幾個方面的問題：

　　企業(yè)網絡的防火墻設置，ACL訪問設置和點對點的數(shù)據(jù)流動問題導致的安全隱患

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

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

　　9、WebRTC 使用場景

WebRTC的使用場景很多，因為WebRTC是一個比較新的技術，因此可能現(xiàn)在仍然有很多新的應用場景不斷出現(xiàn)。現(xiàn)在的使用場景大致分為兩個部分：一種是通信狀態(tài)下的WebRTC使用場景，另外一種是非通信狀態(tài)下的WebRTC使用場景。通信狀態(tài)下的WebRTC使用場景包括以下幾種：
基于頁面的電話/視頻會議
和客戶之間的通信服務，包括UC融合通信，客戶溝通
企業(yè)融合通信/IPPBX/呼叫中心，支持SIP/HTML實現(xiàn)和SIP/PSTN的呼叫
分布式的通信方式/公共服務等
移動端的WebRTC支持，WebRTC不僅僅支持桌面瀏覽器，也支持了安卓/IOS原生態(tài)的API接口
簡單代碼的WebRTC應用場景
通過對攝像頭和麥克風控制實現(xiàn)其他的操作
遠程醫(yī)療/家庭護理
在線客服/現(xiàn)場支持
在線一對一培訓
媒體直播
智能家庭
工業(yè)制造

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

游戲應用包括聊天，共享文件等
Overlay 網絡應用
機器學習
物聯(lián)網
文件共享
虛擬現(xiàn)實游戲

　　10、WebRTC當前狀態(tài)和發(fā)展趨勢

　　雖然WebRTC技術目前應用場景很多，技術發(fā)展也非常迅速。但是，其技術更新也非�？欤x者需要經常查閱官方網站的技術發(fā)展和趨勢。

　　幾個比較重要鏈接如下：

https://www.w3.org/TR/webrtc/
https://w3c.github.io/webrtc-pc/
https://www.w3.org/TR/mediacapture-streams/

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

未來會有更多的瀏覽器支持WebRTC。盡管WebRTC應用有著非常廣的前景，但是目前仍然面對很多挑戰(zhàn)：
各種平臺的兼容性問題，特別是視頻編碼的兼容性
標準化部署的問題
移動平臺的遷移仍然很少
移動端電池壽命的影響
缺乏政府和行業(yè)的標準的支持

　　根據(jù)官方的計劃和市場的要求，未來WebRTC技術仍然需要做的工作很多，幾個主要的工作需要在不久的將來來完成：

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

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

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

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

　　11、WebRTC服務器和開源項目示例

　　我們在前面的技術中已經提到，WebRTC支持了很多中應用場景。其中可能讀者比較感興趣的是視頻會議的一些解決方案。目前，開源的WebRTC服務器都比較受歡迎：

Jitsi
Kurento
Janus WebRTC 網關
Mediasoup

　　下面的示例是一個Kurento 和Asterisk集成的示例，通過Asterisk對SIP終端實現(xiàn)管理，這里，Kurento作為WebRTC的媒體服務器來實現(xiàn)視頻會議的混頻功能。

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

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

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

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

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

　　讀者可以訪問以下鏈接來訪問操作面板：

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

　　12、總結

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

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

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

　　參考資料：

　　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