原標題：WebRTC in the real world:?STUN,?TURN?and signaling

前文鏈接：實際中的WebRTC：STUN，TURN以及信令（一），實際中的WebRTC：STUN，TURN以及信令（二），實際中的WebRTC：STUN，TURN以及信令（三），實際中的WebRTC：STUN，TURN以及信令（四）

?

STUN

NAT給設備提供了一個IP地址以使用專用局域網，但是這個地址不能在外部使用。由于沒有公用地址，WebRTC對等端就無法進行通信。而WebRTC使用?STUN來解決這個問題。

STUN服務器位于公共網絡上，并且有一個簡單的任務：檢查傳入請求的IP地址（來自運行在NAT后面的應用程序），并將該地址作為響應發送回去。換句話說，應用程序使用?STUN服務器從公共角度發現其IP:端口。這個過程使得WebRTC對等端為自己活得一個可公開訪問的地址，然后通過信令機制將其傳遞給另一個對等端以建立直接鏈接。（實際上不同NAT工作方式都有所不同，可能有多個NAT層，但是原理是一樣的）。

因為?STUN服務器不需要做太多的工作或者記特別多的東西，所以相對低規格的?STUN服務器就可以處理大量的請求。

根據webrtcstats.com的統計（2013年），大多數WebRTC通話都成功地使用?STUN進行連接，有86%。盡管對于防火墻之后的對等端之間的呼叫以及復雜的NAT配置，成功通話量會更少一些。

TURN

RTCPeerConnection嘗試通過UDP建立對等端之間的直接通信。如果失敗的話，RTCPeerConnection就會使用TCP進行連接。如果使用TCP還失敗的話，可以用?TURN服務器作為后備，在終端之間轉發數據。

重申：?TURN用于中繼對等端之間的音頻/視頻/數據流，而不是信令數據。

TURN服務器具有公共地址，因此即使對等端位于防火墻或代理之后也可以與其他人聯系。?TURN服務器有一個概念上來講簡單的任務—中繼數據流—但是與?STUN服務器不同的是，他們會消耗大量的帶寬。換句話說，?TURN服務器需要更加的強大。

上圖顯示了?TURN的作用：單純的?STUN沒有成功建立連接，所以每個對等端還需要使用?TURN服務器。

部署?STUN和?TURN服務器

為了進行測試，Google運行了一個公共?STUN服務器?stun.l.google.com:19302，就是apprtc.appspot.com所使用的那樣。對于產品的?STUN/?TURN服務，我們推薦使用rfc5766-turn-server；?STUN和?TURN服務器的源代碼可從code.google.com/p/rfc5766-turn-server獲得，該代碼還提供了有關服務器安裝的多個信息源的鏈接。Amazon Web Services的VM映像也可用。

另一個?TURN服務器是restund，可用作源代碼，也可用于AWS。以下是如何在Google Compute Engine上設置restund的說明。

???????? 1. 根據需要打開防火墻，對于tcp = 443，udp/tcp = 3478

???????? 2. 創建四個實例，每個公共IP標準一個，Standard Ubuntu 12.06映像

???????? 3. 設置本地防火墻配置

???????? 4. 安裝工具：

?????????????????? sudo apt-get install make

?????????????????? sudo apt-get install gcc

???????? 5. 從creytiv.com/re.html安裝libre

???????? 6. 從creytiv.com/restund.html獲取并解壓縮restund

???????? 7. wget?hancke.name/restund-auth.patch并且使用patch – p1

???????? 8. 對libre和restund運行make, sudo make install

???????? 9. 根據你的需要（替換IP地址并確保它包含相同的共享密鑰）對restund.conf進行調整，并復制到/etc

???????? 10. 復制restund/etc/restund到/etc/init.d/

???????? 11. 配置restund：

?????????????????? 設置LD_LIBRARY_PATH

?????????????????? 復制restund.conf到/etc/restund.conf

?????????????????? 設置restund.conf以使用正確的 10. IP地址

???????? 12. 運行restund

???????? 13. 從遠端機上使用社團的客戶端進行測試：./client IP:port

多方WebRTC

你可能還想查看一下Justin Uberti提出的用于訪問TURN服務的REST API的IETF標準。

很容易想象媒體流的使用情況超出了簡單的一對一呼叫：例如，一組同事之間的視頻會議，或一個發言者和數百（數百萬）個關公的公共事件。

WebRTC應用程序可以使用多個RTCPeerConnection，以便每個端點都可以連接到網格配置中的每個其他端點。這是talky.io等應用程序所采取的方法，對于值有少數幾個對等端的情況來說可以很好的工作。除此之外，處理和帶寬會過度消耗，對于移動客戶端來說尤其是這樣。

或者，WebRTC應用程序可以選擇一個端點以星形配置將流分配給所有其他端點。也可以在服務器上運行WebRTC端點并構建自己的重新分配機制。（webrtc.org提供了一個客戶端應用示例）

從Chrome 31和Opera 18開始，來自一個RTCPeerConnection的MediaStream可以用作另一個的輸入：在simpl.info/multi上有一個演示。這可以啟用更靈活的體系結構，因為它使Web應用程序能夠通過選擇要連接的其他對等端來處理呼叫路由。

多點控制單元

大量端點情況的更好選擇是使用多點控制單元（Multipoint Control Unit，MCU）。它是一個服務器，可以作為在大量參與者之間分發媒體的橋。MCU可以處理視頻會議中的不同分辨率，編解碼器和幀速率，處理轉碼，選擇性流轉發，混音或錄制音頻和視頻。對于多方通話，需要考慮許多問題：特別是如何顯示多個視頻輸入并混合來自多個來源的音頻。

你可以購買一個完整的MCU硬件包，或者建立自己的MCU。

有幾個開源的MCU軟件可供選擇。比如說，Licode為WebRTC做了一個開源MCU；OpenTok也有Mantis。

除了瀏覽器以外還有：VoIP，電話和消息

WebRTC的標準化特性使得在瀏覽器中運行的WebRTC應用程序與另一個通信平臺運行的設備或停牌（例如電話或視頻會議系統）之間建立通信成為可能。

SIP是VoIP和視頻會議系統使用的信令協議。為了實現WebRTC應用程序與視頻會議系統等SIP客戶端之間的通信，WebRTC需要代理服務器來調解信令。信令必須通過網關流動，但一旦通信建立，SRTP流量（視頻和音頻）就可以直接流向對等端。

公共交換電話網（PSTN）是所有“普通老式”模擬電話的電路交換網絡。對于WebRTC應用程序和電話之間的通話，通信必須通過PSTN網關。同樣，WebRTC應用程序需要中間的XMPP服務器來與Jingle端點（如IM客戶端）進行通信。Jingle由Google開發，作為XMPP的擴展，為語音和視頻提供消息傳遞服務：當前的WebRTC實現是基于C++ libjingle庫的，這是一個最初為Google Talk開發的Jingle實現。

許多應用程序，庫，和平臺利用WebRTC與外部世界的溝通能力：sipML5，jsSIP，Phono，Zingaya，Twilio和Uberconference等等。

sipML5開發者也構建了webrtc2sip網關。Tethr和Tropo展示了一個在災難通信框架，使用OpenBTS單元通過WebRTC實現手機和計算機之間的通信。這是一個沒有運營商在中間的電話通信！

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的实际中的WebRTC：STUN，TURN以及信令（五）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。