ICE全稱Interactive Connectivity Establishment：互動式連通建立方式。

ICE參照RFC5245建議實現，是一組基於offer/answer模式解決NAT穿越的協議集合。
它綜合利用現有的STUN，TURN等協議，以更有效的方式來建立會話。

客戶端側無需關心所處網路的位置以及NAT型別，並且能夠動態的發現最優的傳輸路徑。

Classic STUN（RFC3489）的劣勢

Classic STUN 有著諸多侷限性，例如:

1. 不能確定獲得的公網對映地址能否用於P2P通訊

2. 沒有加密方法

3. 不支援TCP穿越

4. 不支援對稱型NAT的穿越

5. 不支援IPV6

STUN（RFC5389）協議

RFC5389是RFC3489的升級版

1. 支援UDP/TCP/TLS協議

2. 支援安全認證

ICE利用STUN（RFC5389） Binding Request和Response，來獲取公網對映地址和進行連通性檢查。同時擴充套件了STUN的相關屬性:

1. PRIORITY:在計算candidate pair優先順序中使用

2. USE-CANDIDATE:ICE提名時使用

3. tie-breaker:在角色衝突時使用

TURN協議

ICE使用TURN（RFC 5766）協議作為STUN的輔助，在點對點穿越失敗的情況下，藉助於TURN服務的轉發功能，來實現互通。埠與STUN保持一致

TURN訊息都遵循 STUN 的訊息格式，除了ChannelData訊息。

1. 支援UDP/TCP/TLS協議，適用於UDP被限制的網路。

2. 支援IPV6。

TURN的流程:

• 建立Allocation：

client 使用allocation transaction建立relay 埠，並在allocation的響應中回覆給client。

當allocation建立後需要使用refresh request來保活，預設lifetime為10分鐘。

• 建立Permission：

由allocation建立Permission，每個Permission 由 IP 地址 和lifetime組成。

有兩種方法來建立和重新整理Permission

1. CreatePermission

2. ChannelBind

• 收發資料：

1. CreatePermission使用Send and Data indication訊息

2. ChannelBind使用ChannelData訊息

ICE介紹

1. ICE 的角色

分為 controlling和controlled。

Offer 一方為controlling角色，answer一方為controlled角色。

2. ICE的模式

分為FULL ICE和Lite ICE：

FULL ICE:是雙方都要進行連通性檢查，完成的走一遍流程。

Lite ICE: 在FULL ICE和Lite ICE互通時，只需要FULL ICE一方進行連通性檢查， Lite一方只需回應response訊息。這種模式對於部署在公網的裝置比較常用。

3. Candidate

媒體傳輸的候選地址，組成candidate pair做連通性檢查，確定傳輸路徑，有如下屬性：

• Type 型別有：

Host/Srvflx/Relay/Prflx

• Componet ID

傳輸媒體的型別,1代表RTP;2代表 RTCP。

WebRTC採用Rtcp-mux方式，也就是RTP和RTCP在同一通道內傳輸，減少ICE的協商和通道的保活。

• Priority

Candidate的優先順序。

如果考慮延時，頻寬資源，丟包的因素，Type優先順序高低一般建議如下順序：

host > srvflx > prflx > relay

• Base

是指candidate 的基礎地址。

Srvflx address 的base 是本地host address。

host address和 relayed address 的base 是自身。

4. Candidate pair

由本端和遠端candidate組成的pair，有自己的優先順序。

pair優先順序的計算是取決candidate的priority。

priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

G:controlling candidate 優先順序

D:controlled candidate 優先順序

ICE選擇高優先順序的candidate pair。

5. Checklist

由candidate pair生成按優先順序排序的連結串列,用於ICE連通性檢查。

6. Validlist

由連通性檢查成功的candidate pair按優先順序排序的連結串列,用於ICE提名和選擇最終路徑。

ICE過程

1. Gather candidates

根據Componet ID:

• 獲取本機host address.
• 從STUN伺服器獲取 srvflx address.
• 從TURN伺服器獲取 relay address.
• 同時生成foundation。

2. 刪除重複的candidate

收集地址完成後，需要去掉重複的candidate，如果兩個candidate的地址一樣，並且Base地址也一樣，則刪除它。

3. 交換candidates

ICE 使用offer/answer方式，雙方通過SDP協商交換candidate資訊.

Candidate資訊包括type,foundation,base,component id,transport

SDP a行格式如下:

“a=candidate:1 1 UDP 9654321 212.223.223.223 12345 typ srflx raddr 10.216.33.9 rport 54321”

表示 foundation為1，媒體是RTP，採用UDP協議，公網對映地址為212.223.223.223:12345，優先順序為9654321，type為srflx，base地址為10.216.33.9:54321

4. 生成candidate pairs

在本端收到遠端candidates後，將Component ID和transport protocol相同的candidates組成pair。

修整candidate pair，如果是srvflx地址，則需要用其base地址替換。

對端也是同樣的流程。

5. 生成checklist

將candidate pairs按照優先順序排序，生成checklist，供連通性檢查使用。

6. 連通性檢查

Ordinary checks 兩端都按照各自checklist分別進行檢查。

Triggered checks 收到對端的檢查時，也在對應的candidate pair上發起連通性檢查，以提高效率

如果checklist裡有relay candidate，則必須首先為relay candidate建立permission。

7. 傳送連通性檢查請求

ICE 使用STUN binding request/response，包含Fingerprint檢驗校驗機制。

如果A收到B的response，則代表連通性檢查成功，否則需要進行重傳直到超 時。

在建立連線時，如果沒有響應，則會以RTO時間進行重傳，每次翻倍，直到最大重傳次數。

STUN請求 採用STUN short-term credential方式認證，

STUN USERNAME屬性 ”RemoteUsername：localUsername”

兩端在SDP協商時交換ice-pwd和ice-ufrag，以得對端使用者名稱和密碼。

STUN 檢查請求中需要檢查地址的對稱性，請求的源地址是響應的目的地址，請求的目的地址是響應的源地址，否則都設定狀態為 Failed。

8. 生成validlist

將連通性檢查成功的candidate pair並按優先順序排序加入validlist，這時本地candidate填寫的是公網對映地址，remote candidate填寫的是對端傳送的STUN binding request地址。

9. 提名candidate pair

由controlling來提名哪對candidate pair為valid pair

提名方式又分為普通提名和進取型提名

普通提名方式會做兩次連通性檢查，在第一次做連通性檢查時不會帶上USE-CANDIDATE屬性，而是在生成的validlist裡選擇pair再進行一次連通性檢查，這時會帶上USE-CANDIDATE屬性，並且置位nominated flag。

進取型方式則是每次傳送連通性檢查時都會帶上USE-CANDIDATE屬性，並且置位nominated flag，不會再去做第二次連通性檢查。

10. 選擇最終傳輸地址

ICE在提名的valid pair裡選擇優先順序最高那對作為本次ICE流程傳輸地址。

ICE狀態

1. Waiting：還未開始連通性檢查，從checklist中選擇合適優先順序的pair進行檢查

2. In-Progress：連通性檢查已經開始，但還未結束

3. Succeeded：該pair 連通性檢查已經完成並且成功

4. Failed：失敗

5. Frozen：連通性檢查還未開始

ICE保活

1. 對於每個ICE通道，都需要為其會話進行保活。

2. 採用STUN binding request或者STUN binding indication。

3. 如果沒有收到響應，則會重傳，直到最大重傳次數。

ICE角色衝突解決

1. 當兩端角色都為controlling或者controlled角色衝突時，在連通性檢查階段，要求傳送binding request訊息裡必須要帶上tie-breaker屬性。

2. 當出現衝突時，比較tie-breaker大小，值比較大的則被認為是controlling，同時回應487錯誤給對端，對端收到487錯誤後切換角色。

結束語

隨著WebRTC的應用越來越普遍，無論是Native端還是Web端，由於廣泛的適應 能力以及對未來網路的支援，ICE作為一種綜合的解決方案將有著非常廣闊的應用前景。

網易雲信翻譯了W3C推薦標準WebRTC 1.0: Real-time CommunicationBetween Browsers，並提供《WebRTC1.0: 瀏覽器間實時通訊》中文版免費下載。

· 對於WebRTC初學者，本文件可以作為學習教程，幫助你快速對WebRTC有全面且詳細的瞭解，學習相關API的使用，其附帶的示例程式碼也是很好的學習資料；

· 對於WebRTC資深開發者，本文件可以作為開發中的使用手冊，根據所提供的函式呼叫鏈或是演算法流程進行開發或bug定位；

· 對於高階玩家，也可通過閱讀本文件對WebRTC工作組反饋改進意見。

限時免費下載，WebRTC開發者必備。