WebRTC - TURN和ICE功能

Question

我想了解WebRTC的概念。正如我在一些描述中發現（例如這裏http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png），有進行連接的這樣一種方式：

1. 呼叫STUN，讓你的IP：端口地址。
2. 從TURN獲取一些頻道 - 通過該頻道，您可以將信息發送給其他同行。
3. 發送給其他同齡ICE考生。
4. 接受其他同齡人的ICE候選人 - 開始通話。

問題是，我們需要什麼ICE候選人？我們知道我們的IP，我們可以將它發送到TURN，因此可以發送給其他對等方，並且在TURN我們與其他對等方有良好的連接 - 所以我們不必擔心NAT問題。爲什麼除了我們派遣ICE候選人（爲什麼很多？），以及爲什麼我們需要使用它們呢？

Answer 1

我們這裏有3個主要概念：

• ICE
• TURN
• STUN

的ICE協商並不是那麼簡單...... 爲了執行ICE，UA具有對確定所有候選地址，傳輸地址。傳輸地址是特定傳輸協議的IP地址和端口的組合。有三種類型的候選人：

• 主持人候選人 - 與UA的本地接口相關的傳輸地址
• 接力候選人 - 與TURN服務器相關聯的傳輸地址（只能從一個TURN服務器獲得）
• 服務器自反候選 - 對NAT的公共端轉換的地址

（無論是從STUN服務器或TURN服務器獲得）

UA1收集完所有候選項後，按照優先級從高到低的順序排列它們，並將它們發送到UA2中的SDP提供消息中的屬性。 UA2執行相同的候選人聚會，併發送SDP響應及其候選人名單。每個UA都將這兩個候選人列表進行對比，並將他們配對成候選人對。每個UA將它們收集到檢查列表中，並計劃連通性檢查，STUN請求/響應事務，以查看哪些對工作。圖3顯示了構成UA檢查列表的候選對的組成部分。

ICE將其中一個代理指定爲「控制代理」，將另一個代理指定爲「受控代理」。控制代理使用有效的候選對來提名一對用於媒體。有兩種可用的提名方法：

• 定期提名檢查繼續進行，直到至少有一個有效的候選人對。控制代理從有​​效配對中選擇並在該配對上發送第二個STUN請求，並帶有一個標誌，以告訴對等方這是被提名使用的一個。
• 侵略性提名每次STUN請求都會發送提名標誌，一旦第一次檢查成功完成ICE處理，因爲該媒體流已完成並且不需要第二個STUN請求。

檢查列表中的每個候選對具有與其關聯的狀態。一旦檢查清單被計算出來，狀態由UA分配。有五種可能的狀態：

• 凍結這對只能在被置於等待狀態後才能被檢查。要進入等待狀態，其他檢查必須先成功。
• 等待只要這是檢查列表中最高優先級對，就會執行檢查。
• 正在進行此支付已發送支票，交易正在進行中
• 成功成對檢查成功。
• 失敗對檢查失敗的結果。

以下鏈接包含ICE流程的更多信息和圖表。

參考：

• http://www.vocal.com/networking/ice-interactive-connectivity-establishment/
• RFC https://tools.ietf.org/html/rfc5245#page-9

Answer 2

TURN通常僅當不能建立直接對等網絡連接的回退。後者是困難的部分，也是ICE的目的。

總是使用TURN，是一個選項，但有點邊緣情況。