在本章節和后續章節的討論中，筆者將根據RFC5245/RFC8445的規范架構，結合筆者的這篇歷史文章來(lái)討論WebRTC/ICE的詳細技術(shù)內容。希望通過(guò)筆者完整的討論，讀者可以非常清楚了解WebRTC的流程，特別是關(guān)于ICE的處理。筆者在文章中使用的一些本規范的專(zhuān)有名詞（例如，check 或者check list，事實(shí)上，在本規范中它具有特定的含義），可能沒(méi)有直接以中文的名稱(chēng)來(lái)介紹，這樣做的目的是為了保證不會(huì )產(chǎn)生歧義，所以筆者盡量使用規范中的專(zhuān)有名詞來(lái)解釋。所以，請讀者在閱讀時(shí)一定要注意。

　　說(shuō)明：1）一些專(zhuān)有名詞以前的章節中已經(jīng)發(fā)布，這里不再介紹。2）筆者本人水平有限，文章中所使用的專(zhuān)有名詞中文命名或解釋可能和其他網(wǎng)上的的有所不同，建議讀者參考RFC原文理解或者發(fā)郵件給規范起草人獲得支持。

　　筆者會(huì )在接下來(lái)的內容中重點(diǎn)討論關(guān)于ICE的背景介紹，ICE概覽，ICE使用/ICE候選地址采集和交互，ICE候選對象流程處理，執行連接性檢查，完成ICE創(chuàng )建，輕量級ICE使用介紹等話(huà)題。

　　如果讀者看過(guò)前面的SDP全解的讀者可能已經(jīng)了解，SIP使用了offer/answer結合模式，通過(guò)SDP消息來(lái)實(shí)現媒體傳輸，其最終目的是實(shí)現媒體流之間的創(chuàng )建和完整傳輸。ICE英文全名是Interactive Connectivity Establishment。RFC5245（更新的RFC6336）對ICE做了規定。筆者推薦的一般簡(jiǎn)單的定義是：ICE=STUN+TURN+協(xié)商機制+協(xié)商路徑。

　　但是，因為網(wǎng)絡(luò )越來(lái)越復雜，終端的環(huán)境也發(fā)生了根本變化，因此NAT問(wèn)題也越來(lái)越多。RFC3235規范針對NAT（地址轉換）發(fā)布了一個(gè)指導。很多相關(guān)的協(xié)議希望通過(guò)媒體流之間的點(diǎn)對點(diǎn)傳輸解決媒體本身的問(wèn)題（例如，低時(shí)延，降低丟包，降低部署成本），但是在涉及到NAT環(huán)境時(shí)，通常會(huì )遇到一些更加復雜的問(wèn)題，導致實(shí)際部署的難度大大增加。為了解決NAT的問(wèn)題，很多針對性的技術(shù)規范增加了對NAT環(huán)境的支持，常見(jiàn)的規范包括：

　　隨著(zhù)技術(shù)本身的不斷發(fā)展，這些針對NAT支持的規范也帶來(lái)了很多突出的問(wèn)題，它們都存在各自的優(yōu)缺點(diǎn)。這樣的話(huà)，網(wǎng)絡(luò )管理就會(huì )增加很多的不確定性，給系統管理帶來(lái)很多問(wèn)題。為了解決這些問(wèn)題，一些相關(guān)規范組織希望使用一種統一的解決方式或規范，并且這種協(xié)議可以提供靈活性來(lái)滿(mǎn)足目前網(wǎng)絡(luò )環(huán)境對NAT的支持。目前，大家一致的共識就是使用ICE技術(shù)（Interactive Connectivity Establishment）。此規范通過(guò)offer/answer模式定義ICE來(lái)支持基于UDP的媒體流NAT問(wèn)題（當然，ICE也可以通過(guò)拓展支持ICE-TCP傳輸協(xié)議）。

　　ICE是offer/answer模式的一種拓展形式，通過(guò)在SDP的offer/answer消息中包含多個(gè)地址和端口，使用這些地址端口和其交互消息來(lái)檢測點(diǎn)對點(diǎn)的連接性。在SDP中的地址和端口，以及其連接性檢測是通過(guò)STUN來(lái)完成。

　　圖片來(lái)自于互聯(lián)網(wǎng)資源

　　注意，關(guān)于STUN的最新規范已經(jīng)再次更新（更新時(shí)間為2020年），如果讀者有興趣做進(jìn)一步研究，可參考RFC5389和RFC8489。除了STUN以外，ICE也使用了STUN的另外一個(gè)拓展協(xié)議-TURN（RFC5766）實(shí)現穿越轉發(fā)。另外，因為ICE對每個(gè)媒體流進(jìn)行了多地址和端口交互，它也允許地址選擇支持多宿主和雙棧主機（IPv4/IPv6），因此也不再支持RFC4091和RFC4092。

　　在一個(gè)比較典型的ICE部署環(huán)境中，至少需要兩個(gè)終端需要互相進(jìn)行通信。終端之間可以通過(guò)一些信令結合SDP的offer/answer模式來(lái)實(shí)現，例如，我們前面講的SIP協(xié)議。讀者需要注意，ICE的目的不是為了某些協(xié)議（例如SIP）的NAT穿越，關(guān)于SIP相關(guān)的NAT穿越是通過(guò)RFC5626規定的，如果讀者有興趣的話(huà)，可以查閱此規范。這里，ICE假設終端之間可以創(chuàng )建協(xié)議連接。具體來(lái)說(shuō)，在ICE流程處理開(kāi)始階段，agents就忽略了它們本身的技術(shù)屬性。終端也可能在或不在NAT后（例如后面將的輕量級部署終端），ICE允許終端獲取到技術(shù)屬性的足夠信息，然后找到一個(gè)或多個(gè)潛在的路徑，創(chuàng )建數據會(huì )話(huà)實(shí)現相互連接。

　　圖片均來(lái)自于互聯(lián)網(wǎng)資源

　　在以上示例是一個(gè)非常典型的ICE部署場(chǎng)景示例。兩個(gè)終端分別標識為L(cháng)（左邊）和R（右邊）。兩個(gè)終端都有各自的NAT環(huán)境，雙方也不清楚對端NAT的狀態(tài)屬性，左右雙方終端都有意愿通過(guò)ICE候選對象交互實(shí)現通信。很多時(shí)候，雙方的交互可能都使用SIP協(xié)議。對于雙方終端，SIP服務(wù)器和NAT來(lái)說(shuō)，在網(wǎng)絡(luò )中，ICE經(jīng)常使用STUN和TURN來(lái)保證所有對象的協(xié)同。每個(gè)終端agents可以支持自己獨立的STUN和TRUN服務(wù)器，也可以同一STUN和TURN同一服務(wù)器。基本的ICE工作理念是： 針對傳輸協(xié)議（這里重點(diǎn)討論UDP）每個(gè)agent都有各種候選地址（綁定了IP地址和端口），通過(guò)這種候選地址和對端agent實(shí)現通信。候選地址可能包括：附加到網(wǎng)絡(luò )接口的傳輸地址（server reflexive 地址，其地址是STUN發(fā)現的地址，在NAT外），NAT中公網(wǎng)側的轉換后的傳輸地址，從TURN分配到的傳輸地址（轉發(fā)地址）。客觀(guān)上存在這種可能，任何L側的候選傳輸地址都用來(lái)和任何R側的候選傳輸地址進(jìn)行通信。但是，在實(shí)際場(chǎng)景中，過(guò)多的候選傳輸地址組合可能不能工作。例如，如果L側和R側雙方都在NAT后的話(huà)，直接附加的網(wǎng)絡(luò )接口地址可能不會(huì )直接通信，因此這里需要ICE介入。這里，ICE的目的是發(fā)現何種候選地址配對可以工作。ICE的工作方式是通過(guò)系統地嘗試所有可能的候選配對（排序處理后），直到ICE找到一組或者多組可以工作的候選配對。ICE對Peers的檢測配對需要經(jīng)過(guò)幾個(gè)核心步驟：

　　如果需要執行ICE的話(huà)，agent首先需要確認候選地址。候選地址是一種特別的地址，它是由IP地址和端口的組合構成，其目的是支持傳輸協(xié)議（我們這里僅討論UDP）。RFC8445定義了三種候選地址，一種是來(lái)自于物理網(wǎng)絡(luò )接口，另外一種來(lái)自于網(wǎng)絡(luò )的邏輯接口，還有一種是通過(guò)STURN或者TURN發(fā)現的候選地址。第一種類(lèi)別的候選地址支持的傳輸地址直接從本地網(wǎng)絡(luò )接口獲得。這樣的候選地址我們稱(chēng)之為“host candidate”，這樣類(lèi)型的本地地址可以從本地網(wǎng)絡(luò )，WIFI，遠端網(wǎng)絡(luò )或者VPN的方式獲得。對agent來(lái)說(shuō)，這樣的地址都可以通過(guò)分配獲得，并且作為本地接口來(lái)使用。如果agent是一個(gè)多宿主主機的話(huà)，它可以從不同的IP地址獲得候選地址。具體的候選地址如何獲得取決于網(wǎng)絡(luò )中peer（會(huì )話(huà)中另外一個(gè)agent）的位置。例如，如果agent支持了兩個(gè)不同的IP地址的話(huà)（一個(gè)是內網(wǎng)地址，一個(gè)是外網(wǎng)地址），不同的peer就可以通過(guò)不同的地址和agent通信。

　　另外一種候選地址是agent使用STUN或TURN獲得的額外的候選地址，這些候選地址主要表現為兩種地址形式：NAT公網(wǎng)側的已轉換地址（server-reflexive 候選地址），TURN服務(wù)器分配的轉發(fā)地址（relayed 候選地址）。這里讀者一定要注意兩種地址的獲取方式。當使用TURN服務(wù)器時(shí)，以上兩種候選地址都來(lái)自于TURN服務(wù)器分配地址；當僅使用了STURN服務(wù)器的話(huà)，agent只能獲取到server reflexive地址。以下是候選地址的關(guān)系示例圖：

　　在以上關(guān)系圖中，兩種類(lèi)型的候選地址都是通過(guò)TURN服務(wù)器發(fā)現獲得的。這里的地址端口配對中，大寫(xiě)X表示IP地址，小寫(xiě)x表示UDP端口。當agent對IP地址和端口發(fā)送一個(gè)（X:x）TURN地址分配請求時(shí)，NAT（假設這里有NAT）就會(huì )創(chuàng )建一個(gè)綁定關(guān)系X1':x1'，映射server-reflexive地址到主機候選地址。從本地主機候選地址發(fā)送出去的數據包將會(huì )通過(guò)NAT地址轉換變成一個(gè)server-reflexive候選地址。同樣的道理，從server-reflexive候選地址進(jìn)入到主機候選地址的數據也是通過(guò)NAT地址轉換完成。這里，base是一個(gè)比較重要的概念，需要讀者明確，“base"是一個(gè)本地主機候選地址，它關(guān)聯(lián)一個(gè)給定的server-reflexive候選地址。base指的是一個(gè)agent為指定的候選地址發(fā)出數據的地址。因此，有時(shí)存在一個(gè)比較極端的場(chǎng)景，主機候選地址也可以有自己的base地址，這個(gè)base 地址和主機候選地址相同。

　　來(lái)自于互聯(lián)網(wǎng)資源

　　當agent和TURN服務(wù)器存在多個(gè)NAT穿越時(shí)，TRUN請求會(huì )為每個(gè)NAT創(chuàng )建一個(gè)綁定，但是agent僅發(fā)現最外部的server-reflexive候選地址（距離TRUN服務(wù)器最近的候選地址）。如果agent不在NAT后的話(huà)，base 候選地址和server-reflexive候選地址相同，server-reflexive候選地址就會(huì )被移除。

　　Agent發(fā)出的分配請求到達TURN服務(wù)器端后，TURN服務(wù)器將會(huì )從它的本地IP地址Y中分配一個(gè)端口y，并且生成一個(gè)分配響應，分配響應通知一個(gè)agent的轉發(fā)候選地址。TRUN服務(wù)器也會(huì )通知一個(gè)agent的server-reflexive候選地址X1':x1'，通知的方式是把分配請求中的源傳輸地址拷貝到分配響應中來(lái)實(shí)現。TRUN服務(wù)器的工作角色類(lèi)似于一個(gè)在L側和R側之間的數據轉發(fā)。如果R側想對L側發(fā)送數據的話(huà)，R側需要發(fā)送數據到Y:y 地址，然后TRUN服務(wù)器端前轉到X1':x1'候選地址，然后經(jīng)過(guò)NAT后映射到L側agent。

　　當僅使用了STUN服務(wù)器時(shí)，agent發(fā)送一個(gè)STUN綁定請求給它的STUN服務(wù)器，STUN將會(huì )通知一個(gè)agent的server-reflexive候選地址X1':x1'，其通知的方式是綁定請求中的源傳輸地址拷貝到綁定響應中。

　　一旦L側agent采集到它所有的候選地址后，它會(huì )把這些地址重新按照從最高到最低的排序，然后通過(guò)信令通道發(fā)送給R側agent。這些候選地址通過(guò)SDP的offer消息的屬性參數發(fā)送到R側agent（開(kāi)始使用offer/answer交互模式）。當R側agent收到offer消息后，R側的agent也會(huì )執行一個(gè)同樣的流程來(lái)采集候選地址，然后通過(guò)響應消息返回自己的候選地址。雙方采集發(fā)送流程完成以后，每個(gè)agent都有自己的完整的候選地址和對待peer的完整候選地址。通過(guò)雙方候選地址的配對處理，最后產(chǎn)生一個(gè)候選配對。候選地址配對產(chǎn)生以后，agent首先需要知道哪個(gè)候選地址配對是可以工作的，每個(gè)agent會(huì )按時(shí)設定一系列的檢查。每個(gè)檢查是一個(gè)STUN請求響應的事務(wù)，每個(gè)終端都會(huì )執行具體的候選地址配對流程，配對流程檢查通過(guò)本地候選地址對遠端候選地址發(fā)送一個(gè)STUN請求。連接性檢查（Connectivity Checks）的基本原理非常簡(jiǎn)單：

　　因此，在執行候選配對檢查時(shí)需要一個(gè)四次握手的處理：

　　基本候選地址配對檢查四次握手處理流程

　　這里一定要注意，發(fā)送STUN請求的目的地和接收源的IP地址和端口，這是完全相同的IP地址和端口，使用此IP地址和端口來(lái)傳輸媒體流（包括RTP和RTCP）。因此，agent會(huì )通過(guò)數據內容多路分解STUN/RTP/RTCP相關(guān)數據，而不使用其接收端口來(lái)分解STUN/RTP/RTCP數據。相對于使用端口的方式來(lái)說(shuō)，多路分解方式會(huì )更容易處理檢查狀態(tài)，特別是針對RTP和RTCP的數據。因為，STUN綁定請求是用來(lái)執行連接檢查的，在STUN響應中包含了agent的已轉譯的傳輸地址，這個(gè)地址是agent和對端peer之間的NAT公網(wǎng)側地址。如果這個(gè)傳輸地址和agent已學(xué)習過(guò)的候選地址不同的話(huà)，agent就會(huì )知道這個(gè)候選地址是一個(gè)新的地址（PEER REFLEXIVE CANDIDATE），這個(gè)新地址和其他候選地址一樣，也是ICE測試過(guò)的地址。

　　作為一種優(yōu)化方式，只要R側獲得了L側的檢查消息，R側會(huì )在同一候選配對中按時(shí)對L側發(fā)送一個(gè)連接檢查消息。這樣的話(huà)，ICE就會(huì )加快發(fā)現有效候選流程處理時(shí)間，這個(gè)過(guò)程也稱(chēng)之為“TRIGGERED CHECK”。在雙方握手完成以后，雙方都知道對對端可以接收或者發(fā)送端對端消息。到此為止，連接檢查結束。

　　根據連接檢查的介紹，讀者可能已經(jīng)注意到了，前面我們討論的候選配對查詢(xún)算法還有一定的問(wèn)題，假設候選配對存在的話(huà)，無(wú)論查詢(xún)方式是何種順序，查詢(xún)流程會(huì )一直查詢(xún)直到找到這一對候選配對。顯然，查詢(xún)的順序肯定影響候選配對的查詢(xún)結果。因此，為了快速生成候選配對結果，候選地址需要經(jīng)過(guò)排序處理，最后，排序后的候選配對結果就是一個(gè)check list。關(guān)于排序算法筆者在發(fā)送初始offer的章節進(jìn)行討論。基本上，排序算法需要遵守兩個(gè)基本原則：

　　每個(gè)agent給它的候選地址一個(gè)優(yōu)先級數字標識，此優(yōu)先級標識會(huì )隨候選地址發(fā)送到對端peer。

　　本地和遠端優(yōu)先級合并，每個(gè)agent針對候選配對來(lái)說(shuō)有一個(gè)同樣的排序。

　　其中，第二個(gè)原則非常重要。如果雙方L側agent和R側agent的都在NAT后的話(huà)，為了確保ICE工作，必須特別注意第二個(gè)原則。我們經(jīng)常可以看到，NAT是不會(huì )允許一臺外部主機發(fā)送數據進(jìn)入到NAT后的網(wǎng)絡(luò )環(huán)境中，只有在NAT后的agent通過(guò)NAT發(fā)送數據給這臺主機后才被允許交互，外部數據才能進(jìn)入到NAT后的環(huán)境中。這里要注意，直到agent雙方都已通過(guò)自己相關(guān)的NAT穿越發(fā)送check信息后，雙向的ICE check才能最終成功。agent需要通過(guò)check list才能啟動(dòng)工作，所以，它需要周期性地發(fā)送一個(gè)STUN請求獲得列表中的候選配對。這個(gè)處理過(guò)程稱(chēng)之為 “ORDINARY CHECKS”。

　　通常情況下，優(yōu)先級算法的設計是為了同類(lèi)候選地址直接獲得同樣的優(yōu)先級，和一些非直接處理的方式相比，優(yōu)先級算法在處理候選配對是可能更加高效。因此，通過(guò)優(yōu)先級算法的處理流程可以快速高效地實(shí)現直接路由訪(fǎng)問(wèn)，路由處理路徑中僅需要幾個(gè)媒體轉發(fā)和幾個(gè)NAT轉發(fā)。如果采用非直接處理的方式的話(huà)，候選配對可能需要更多媒體轉發(fā)和NAT轉發(fā)，經(jīng)過(guò)越多的轉發(fā)就會(huì )導致越多的不可控因素。所以，這樣的方式不是一種好的推薦的方式。但是，agent都有自己的決定權來(lái)優(yōu)化算法。

　　前面的討論中，我們僅僅描述了一種場(chǎng)景，那就是agents想使用一個(gè)組件模塊（COMPONENT）創(chuàng )建一個(gè)媒體會(huì )話(huà)。這里，COMPONENT是一個(gè)媒體流。在典型的應用環(huán)境中，agents實(shí)際需要創(chuàng )建一個(gè)連接來(lái)支持更多的數據流程。網(wǎng)絡(luò )環(huán)境中的很多屬性和組件具有非常大的相似度。通常情況下，如果一個(gè)組件模塊可以工作的話(huà)，我們會(huì )借用同樣的信息來(lái)決定最近的候選地址。ICE使用這樣的處理方式來(lái)處理候選配對流程，這種算法簡(jiǎn)稱(chēng)為frozen candidates或者鎖定候選算法。每個(gè)候選地址都和自己的一個(gè)屬性相關(guān)聯(lián)，我們稱(chēng)這個(gè)屬性為“FOUNDATION”。如果它們被認為是“相似”的話(huà)，我們就會(huì )認為他們具有相同的FOUNDATION屬性，這表示它們有相同的類(lèi)型，并且都是從同一host candidate，同樣的STUN服務(wù)器，使用同樣的協(xié)議獲得的類(lèi)型數據。否則，這樣的候選地址就是不同的。同樣的道理，候選配對也有FOUNDATION屬性。這個(gè)候選配對的FOUNDATION就是通過(guò)合并候選地址的FOUNDATION構成。在初始階段，只有針對FOUNDATION是唯一狀態(tài)的候選配對進(jìn)行測試。其他的候選配對會(huì )被標識為“frozen” 或者鎖定狀態(tài)。當候選配對的連接檢查是成功狀態(tài)的話(huà)，其他帶相同FOUNDATION屬性的候選配對被unfrozen或者解封。通過(guò)這樣的方式就可以避免了重復的連接性檢查，增加檢查的效率。但是，事實(shí)上，這種方式也有失敗的可能。frozen candidates是ICE處理流程的一部分，ICE有優(yōu)先級的算法會(huì )自動(dòng)使用正確的順序確保正確的候選地址被解封。

　　這里筆者再花費一點(diǎn)時(shí)間再一點(diǎn)補充說(shuō)明。在筆者接觸到的資源中，很多關(guān)于WebRTC/ICE的技術(shù)討論，以及相關(guān)的官方中，包括RFC5245本身也沒(méi)有非常完整地解釋清楚“frozen”的定義。這里，筆者試圖借用一定的示例來(lái)進(jìn)一步明確說(shuō)明frozen candidates的具體含義。首先，我們來(lái)解釋一下在我們討論的場(chǎng)景中具體的frozen定義。如果我們單純從字面意思， 筆者認為可以理解frozen為封凍或者鎖定的含義。接下來(lái)讀者就容易理解frozen candidates的完整含義。從前面的解釋?zhuān)�我們可以看到frozen candidates就是一種候選地址的狀態(tài)。

　　來(lái)自于互聯(lián)網(wǎng)資源

　　每個(gè)在check list中的候選配對都有自己的狀態(tài)，具體的狀態(tài)處理經(jīng)過(guò)以下幾個(gè)步驟：

　　大家知道，ICE的目的是發(fā)現兩個(gè)agent之間的地址，通過(guò)這個(gè)地址來(lái)發(fā)送媒體流數據。當然，ICE必須確保這個(gè)地址不能出現安全問(wèn)題，也必須避免把媒體數據發(fā)送到錯誤的地址。每個(gè)STUN的連接性檢查都要經(jīng)過(guò)消息認證碼（MAC）的計算，消息認證碼在信令通道中使用密鑰交換的方式進(jìn)行計算。因為MAC提供了消息完整性和數據原始認證，因此它可以杜絕攻擊者偽造和修改連接性檢查消息內容。一個(gè)比較典型的例子就是SIP的分叉呼叫處理。如果SIP呼叫用戶(hù)正在使用ICE，并且此呼叫進(jìn)行了分叉呼叫處理的話(huà)，ICE處理就會(huì )在每個(gè)獨立的接收方之間進(jìn)行。這種使用場(chǎng)景中，在信令通道中的密鑰交換幫助每個(gè)ICE交換和其分叉的接收方進(jìn)行交換處理。如果讀者不了解分叉呼叫的內容，可以查閱本微信號的歷史文章-關(guān)于分叉呼叫流程的處理。

　　通過(guò)前面的介紹，我們知道ICE檢查是需要按照順序處理的。ICE首先處理優(yōu)先級最高的候選配對，然后再處理低優(yōu)先級的候選配對。只要每個(gè)模塊的媒體流檢查都成功以后，ICE通過(guò)聲明一個(gè)“成功”表示候選配對成功，整個(gè)ICE的創(chuàng )建就完成了。這種操作方式確實(shí)也是比較合理的，我們會(huì )在后續的文章中介紹具體的算法。但是，任何事情都有其兩面性，通過(guò)這種按照優(yōu)先級高低來(lái)執行候選配對檢查的算法需要考慮一定的風(fēng)險。如果最高優(yōu)先級的候選配對產(chǎn)生了數據丟失的問(wèn)題，這樣就會(huì )耗費了稍長(cháng)時(shí)間完成配對檢查。這種情況下，ICE可能需要花費稍長(cháng)時(shí)間，但是可能會(huì )產(chǎn)生比較好的結果。從根本上來(lái)說(shuō)，RFC5245官方規定的優(yōu)先級算法不一定會(huì )產(chǎn)生“優(yōu)化”的結果。如果其算法的目的是選擇低時(shí)延的媒體路徑的話(huà)，使用了轉發(fā)（轉發(fā)可能是高延時(shí)）作為一種建議提示的話(huà)，這種轉發(fā)建議實(shí)際上就沒(méi)有多大關(guān)系。實(shí)際場(chǎng)景中可能使用往返時(shí)延（RTT）的衡量指標的方式可能比優(yōu)先級的處理方式更好，在演示中場(chǎng)景中，低優(yōu)先級的候選配可能比高優(yōu)先級的候選配對取得更低的時(shí)延。

　　標識成功配對以后，接下來(lái)，ICE就會(huì )指定agent的功能角色。其中一個(gè)agent稱(chēng)之為CONTROLLING AGENT（主控agent），另外一個(gè)agnet是CONTROLLED AGENT（被控agent）。主控agent就會(huì )從有效的候選配對中指定一個(gè)配對來(lái)應對媒體處理。主控agent通過(guò)兩種方式來(lái)實(shí)現指定候選配對：使用regular nomination或者使用aggressive nomination的方式來(lái)指定候選配對。

　　來(lái)自于互聯(lián)網(wǎng)資源

　　使用regular nomination正常指定候選配對的話(huà)，主控方agent會(huì )一直發(fā)送請求消息，讓check處理進(jìn)行處理，直到找到至少一個(gè)有效的候選配對可以支持媒體。然后選擇其有效的候選配對。接下來(lái)主控agent仍然會(huì )繼續發(fā)送第二個(gè)STUN請求消息，但是，在第二個(gè)STUN請求中，主控agent會(huì )附加一個(gè)flag，通知對端，主控agent已經(jīng)指定了一個(gè)候選配對，將要使用那個(gè)候選配對來(lái)處理媒體流。當攜帶flag的這個(gè)STUN事務(wù)完成以后，雙方都取消了進(jìn)一步的check流程。ICE將使用最終指定的那個(gè)有效配對發(fā)送媒體。ICE正在使用的這對候選配對稱(chēng)之為“SELECTED PAIR”，成為已選配對。所以，讀者一定要明白，ICE是真正使用selected pair來(lái)進(jìn)行媒體處理的，前面所有的候選配對都是為ICE最后選擇配對進(jìn)行準備。

　　上面，筆者介紹了正常指定配對的方式，這里我們再介紹一下aggressive nomination的使用方式。aggressive nomination的方式相對比較激進(jìn)或主動(dòng)一點(diǎn)。主控agent使用aggressive nomination時(shí)，主控agent會(huì )在每個(gè)STUN請求中附加一個(gè)flag，一旦找到第一個(gè)成功的配對的話(huà)，ICE就會(huì )結束其他的檢查流程，然后使用其配對處理媒體，主控agent不會(huì )再發(fā)送第二個(gè)STUN請求。此selected pair具有最高的優(yōu)先級。所以，我們通過(guò)兩種方式的介紹，我們可以看出，aggressive nomination檢查速度快，但是缺少靈活性；regular nomination則處理速度慢，但是可能會(huì )找到低時(shí)延的媒體路徑。

　　一旦所有的媒體處理完成后，如果媒體中“m=”和“c=”行中的候選地址（默認候選）不能匹配selected pair（已選配對）的話(huà)，主控端會(huì )發(fā)送一個(gè)更新offer消息。如果ICE結束后，為了支持agent的媒體流，任何一方agent都可以在任何時(shí)間重新啟動(dòng)ICE。重新啟動(dòng)ICE可以通過(guò)agent發(fā)送一個(gè)更新offer的方式來(lái)處理。

　　為了讓呼叫支持ICE，雙方agent必須都使用ICE。但是，在實(shí)際環(huán)境中，某些agent本身就帶了公網(wǎng)地址，它可以從任何通信端接收數據或者進(jìn)行通信。為了讓這類(lèi)終端能夠方便地支持ICE，ICE定義了一種特別的部署方式，稱(chēng)之為lite implementation，或者輕量級部署方式。當然，相對于lite implementation的支持方式，ICE支持正常的full implementation全部署方式。因為這類(lèi)帶國外地址的終端本身帶有公網(wǎng)地址，所以，輕量級的部署方式會(huì )減少很多中間處理環(huán)節。首先，它不采集候選地址，它也不包含支持媒體的主機候選地址（一般的內網(wǎng)地址）。另外，雖然它們需要返回響應消息，但是，這類(lèi)agent不會(huì )生成連接檢查或運行狀態(tài)機。當兩個(gè)輕量級agent連接時(shí)無(wú)需發(fā)送檢查請求響應消息；可是，當使用輕量級agent和全部署方式連接時(shí)，這時(shí)，全部署方式的agent會(huì )變?yōu)橹骺豠gent來(lái)控制檢查流程，輕量級agent就會(huì )變?yōu)楸豢豠gent。筆者將會(huì )在后續章節或者文章中討論這兩種部署方式的具體細節。讀者需要特別注意，輕量級的部署是針對全部署方式的一種補充方式，是在RFC5245中稍晚時(shí)間增加的功能支持。針對那些支持公網(wǎng)地址的終端來(lái)說(shuō)，如果可以實(shí)現全部署方式的話(huà)，RFC5245推薦使用全部署方式。

　　以上都是關(guān)于ICE的熱身流程，包括了基本的概念以及大概的處理流程。后續文章中，筆者將繼續介紹ICE處理流程和具體細節，從真正的第一步處理流程開(kāi)始-初始化offer的處理，包括初始化offer中的Full Implementation 要求和其具體步驟。

　　https://anyconnect.com/stun-turn-ice/

　　https://tools.ietf.org/id/draft-ietf-ice-rfc5245bis-13.html

　　https://tools.ietf.org/html/rfc8445

　　https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment

　　https://www.ietfjournal.org/interactive-connectivity-establishment/

　　https://ietf.org/documents/144/IETF_ICE_intro_92.pdf

　　

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　Asterisk freepbx FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　融合通信/IPPBX商業(yè)解決方案：www.hiastar.com

　　如何使用FreeSBC，qq技術(shù)分享群：334023047, www.freesbc.cn