所有ICE的部署需要符合RFC5389中STUN的規范（已經(jīng)更新為RFC8489）。大家知道，全部署場(chǎng)景的agent才是ICE部署中核心內容。全部署場(chǎng)景agent需要扮演STUN客戶(hù)端（生成檢查）和STUN服務(wù)器端（接收檢查）的兩種角色。輕量級的agent則作為服務(wù)器端只能接收檢查（check）。因此，我們所討論的內容將以SUTN客戶(hù)端生成流程和服務(wù)器端接收流程兩個(gè)部分的內容進(jìn)行討論。其中，STUN客戶(hù)端流程主要包括：

　　服務(wù)器端主要流程包括：

　　筆者會(huì )根據以上的內容逐一進(jìn)行討論。首先，筆者將介紹關(guān)于STUN客戶(hù)端的流程處理。

　　1STUN客戶(hù)端流程總覽
　　這里，筆者首先說(shuō)明一下關(guān)于STUN客戶(hù)端的發(fā)送流程。STUN客戶(hù)端發(fā)送連接檢查（connectivity checks），確認連接檢查是一個(gè)ordinary還是triggered check。另外，筆者說(shuō)明一下，以下討論的流程僅支持全部署場(chǎng)景agent。

　　為了保證安全，筆者在前面的文章中也提到過(guò)，轉發(fā)也需要一個(gè)權限要求。如果使用relayed 本地候選地址發(fā)送連接檢查的話(huà)，如果以前沒(méi)有創(chuàng )建轉發(fā)權限的話(huà)，客戶(hù)端必須首先需要創(chuàng )建一個(gè)轉發(fā)權限，允許通過(guò)relayed本地候選地址進(jìn)行轉發(fā)。如果已經(jīng)有已創(chuàng )建的轉發(fā)權限的話(huà)，agent可以使用這個(gè)權限。如果需要創(chuàng )建轉發(fā)權限的話(huà)，agent轉發(fā)權限需要根據一定的流程來(lái)實(shí)現權限處理。具體的權限創(chuàng )建流程讀者可以參與RFC5766-8和9章節。創(chuàng )建好的權限必須支持遠端候選地址。一種情況需要特別處理，agent在正常情況下，發(fā)送CreatePermission請求進(jìn)行連接檢查創(chuàng )建時(shí)，RFC5245規范推薦agent要延遲TURN通道創(chuàng )建，直到ICE完成后再開(kāi)始創(chuàng )建。一旦權限創(chuàng )建完成以后，agent必須維護權限的活動(dòng)狀態(tài)，一直到ICE結束此流程。

　　2發(fā)送請求
　　在STUN客戶(hù)端處理流程中，本地候選地址對遠端候選地址發(fā)送綁定請求（Binding request），發(fā)送此請求后生成一個(gè)check。關(guān)于綁定請求的具體構建和生成，讀者可以參與RFC8489。連接檢查的安全策略必須使用STUN短期安全機制來(lái)實(shí)現。關(guān)于STUN短期安全機制（用戶(hù)名稱(chēng)/密碼+時(shí)間限定）和長(cháng)期安全機制筆者在以前也做過(guò)介紹，讀者也可以查閱RFC8489-9.1章節了解更多細節。注意，不能使用RFC3489實(shí)現向后兼容的支持能力。連接檢查必須使用FINGERPRINT機制來(lái)實(shí)現STUN消息區分。關(guān)于FINGERPRINT機制的定義，讀者可以查閱RFC8489-7。

　　ICE通過(guò)定義四個(gè)新屬性拓展了對STUN支持，這四個(gè)屬性分別是PRIORITY，USE-CANDIDATE，ICE-CONTROLLED，和ICE-CONTROLLING。在接下來(lái)的章節中筆者分別介紹這四個(gè)新定義的拓展屬性。注意，這四個(gè)STUN拓展的新屬性?xún)H支持ICE的連接檢查。

　　3ICE定義的四個(gè)新STUN拓展說(shuō)明
　　如果agent發(fā)送綁定請求時(shí)，它必須在其綁定請求中包含一個(gè)PRIORITY拓展屬性。agent必須設定這個(gè)PRIORITY等于候選優(yōu)先級排序中設定的那個(gè)權限設置。對于反射候選地址來(lái)說(shuō)，這個(gè)優(yōu)先級可以通過(guò)檢查結果的學(xué)習來(lái)獲得。除了反射候選地址中的偏好類(lèi)型設置為此偏好設置以外，此優(yōu)先級值計算和本地候選地址配對計算也是一樣的。

　　在綁定請求中，被控方agent可以包含一個(gè)USE-CANDIDATE。但是，主控方一定不能在綁定請求中包含此拓展屬性。此STUN拓展屬性USE-CANDIDATE表示的意思是被控方agent希望退出此構件中的檢查，使用來(lái)自于此構件中的候選配對執行檢查。這里涉及了一個(gè)配對推薦的具體流程，筆者在未來(lái)的文章中將具體討論此指導原則和此STUN拓展的使用。

　　其余兩個(gè)拓展屬性根據角色不同選擇包含不同的屬性。具體來(lái)說(shuō)，如果agent是在一個(gè)主控方角色中的話(huà)，在agent發(fā)送綁定請求時(shí)，它必須在請求中包含ICE-CONTROLLED拓展屬性。如果是在被控方agent中的話(huà)，它必須在綁定請求中包含一個(gè)ICE-CONTROLLING拓展屬性。當然，兩種角色可能會(huì )因為會(huì )話(huà)不同其內容也可能不同，具體關(guān)于其角色決定的內容處理，筆者在前面的文章中有非常詳細說(shuō)明。

　　4構建安全信息
　　除了agent發(fā)送綁定請求中需要各自包含所需要的拓展屬性以外，agent同時(shí)也需要發(fā)送一定的安全信息來(lái)實(shí)現安全驗證。綁定請求作為一種連接檢查，它也必須使用STUN短期安全機制。STUN短期安全機制需要用戶(hù)名稱(chēng)和密碼。安全策略中的用戶(hù)名稱(chēng)是本地agent的用戶(hù)名稱(chēng)和遠端peer的用戶(hù)名稱(chēng)的合并名稱(chēng)（通過(guò)括號分開(kāi)），密碼是遠端peer提供的密碼。這里的策略設置比較迷惑，讀者一定要注意。

　　連接檢查用戶(hù)安全構件組合具體連接檢查的處理方式如上圖示例，根據連接檢查的方向不同，用戶(hù)名稱(chēng)和密碼的選擇組合是不同的。如果從L側發(fā)起，L端agent需要對R端agent進(jìn)行連接檢查的話(huà)，它的用戶(hù)名稱(chēng)組合方式是（RFRAG：LFRAG），密碼是RPASS；反之亦然，如果從R端發(fā)起連接檢查，其用戶(hù)名稱(chēng)組合是（LFRAG：RFRAG），密碼是LPASS密碼。返回響應時(shí)，響應處理使用的用戶(hù)名稱(chēng)/密碼和請求中的相同（USERNAME屬性不會(huì )出現）。

　　5區分服務(wù)處理
　　如果agent在媒體數據中（例如在QoS中）使用了區分服務(wù)-Diffserv（遵從RFC2475），agent也應該對連接檢查使用同樣的標識方式。因為區分服務(wù)不在我們討論的范圍，具體關(guān)于Diffserv，讀者查閱RFC2475，這里不做進(jìn)一步討論。

　　6處理響應
　　當收到響應以后，這個(gè)響應需要使用事務(wù)ID和其綁定請求關(guān)聯(lián)在一起。這個(gè)綁定關(guān)聯(lián)的處理流程在RFC5389或RFC8489中定義。然后agent把響應綁定到候選配對上，這個(gè)候選配對是綁定請求以前發(fā)送的候選配對。針對具體的STUN使用中關(guān)于失敗響應和成功響應的不同場(chǎng)景，這個(gè)部分定義了額外的步驟來(lái)處理這些流程。下面，我們專(zhuān)門(mén)針對失敗響應處理和成功響應處理做進(jìn)一步的介紹。

　　7失敗響應場(chǎng)景和成功響應場(chǎng)景詳解
　　失敗響應有很多種。如果STUN事務(wù)生成一個(gè)487錯誤碼，這表示agent角色沖突。agent需要檢查在請求綁定中是否包含了前面所說(shuō)的拓展屬性ICE-CONTROLLED或ICE-CONTROLLING。如果請求包含的是ICE-CONTROLLED屬性，agent還沒(méi)有完成角色切換的話(huà)，它必須切換到主控方角色。如果請求包含的是ICE-CONTROLLING屬性，agent還沒(méi)有完成角色切換的話(huà)，它必須切換到被控方角色。一旦agent完成切換的話(huà)，它必須對生成487錯誤的候選配對進(jìn)行入隊處理，然后這個(gè)隊列進(jìn)入到triggered check queue中。然后將此配對狀態(tài)設置為等待狀態(tài)。當triggered check發(fā)送以后，它將包含一個(gè)ICE-CONTROLLED或ICE-CONTROLLING屬性，這個(gè)屬性反映它新的角色。這里注意，tie-breaker的值一定不能重選。

　　角色切換以后，需要進(jìn)一步的計算。因為不同角色具有不同的功能，因此agent需要重新計算配對優(yōu)先級（前面文章有介紹）。另外，角色切換還會(huì )影響agent所負責的其他功能，例如基于ICE結果選擇推薦配對，和生成更新的offer消息。除了ICMP錯誤以外，因為環(huán)境不同，可能STUN事務(wù)還能生成其他的錯誤響應。Agent也可以支持針對連接檢查的ICMP錯誤接收的工作。如果STUN事務(wù)生成ICMP錯誤，agent將會(huì )設置此配對為錯誤狀態(tài)。如果STUN事務(wù)生成的錯誤是不可恢復的錯誤或者超時(shí)錯誤的話(huà)，agent也會(huì )設置此配對的狀態(tài)為錯誤狀態(tài)。關(guān)于不可恢復的錯誤，讀者可以查閱RFC5389-7.3.4章節關(guān)于錯誤的詳解。

　　Agent必須檢查源IP地址和響應端口是否等同于目的地地址和端口（目的地地址和端口是綁定請求發(fā)送過(guò)去的地址和端口），并且響應中的目的地地址和端口是否匹配源地址和端口（源地址和端口是從綁定請求中發(fā)送的）。換句話(huà)說(shuō)，在請求和響應中的源地址和目的地傳輸地址是對稱(chēng)的。如果這兩組地址不對稱(chēng)，agent將會(huì )設置此配對是失敗狀態(tài)。

　　以上筆者討論的是檢查失敗響應的處理。現在，筆者討論成功響應的處理。如果檢查成功的話(huà)，檢查成功，以下所有條件必須為真：

　　獲得成功響應以后，agent需要進(jìn)一步對響應消息和候選配對進(jìn)行處理。其流程需要經(jīng)過(guò)四個(gè)步驟的處理。筆者繼續分別介紹這幾個(gè)流程。

　　第一個(gè)步驟是發(fā)現peer的反射候選地址。Agent需要從響應中檢查映射地址。如果傳輸地址不能匹配agent獲知的任何本地候選地址，映射地址表示一個(gè)新候選地址，此地址就是peer反射候選地址。此反射候選地址和其他的候選地址一樣，同樣具有類(lèi)型，基準地址，優(yōu)先級和foundation。這四個(gè)屬性的計算方式如下：

　　計算以后，peer反射候選地址（peer reflexive candidate）會(huì )添加到媒體流的本地候選地址列表中。對此媒體流來(lái)說(shuō)，其用戶(hù)名稱(chēng)和密碼和其他本地候選地址的相同。但是，peer反射候選地址不會(huì )和其他遠端候選地址配對。在此流程中，也沒(méi)有必要進(jìn)行反射地址和遠端地址的配對處理。一對有效的配對會(huì )立刻通過(guò)構建有效配對的流程進(jìn)行處理（此章節第二個(gè)步驟介紹）。如果agent希望peer反射候選地址和其他遠端候選進(jìn)行配對的話(huà)（這個(gè)遠端候選地址不在將生成的有效配對內），agent可以生成一個(gè)更新的offer，在此offer中包含peer反射候選地址。通過(guò)這樣的方式，agent可以完成此peer反射候選地址和其他遠端候選地址配對的流程。

　　發(fā)現了反射候選地址以后，第二步的流程就是構建有效配對。agent可以開(kāi)始構建一對候選配對。候選配對中，它的本地候選地址等同于響應中的映射地址，它的遠端候選地址等同于綁定請求中發(fā)送的目的地地址。因為它們的有效性已經(jīng)通過(guò)STUN連接檢查驗證，這樣的配對稱(chēng)之為有效配對。讀者需要注意，有效配對可能來(lái)自于不同的配對。具體來(lái)說(shuō)，有效配對可能等同于檢查生成的配對，可能等同于檢查列表中不同的配對，或也可能是一對當前不在檢查列表中的配對。如果這個(gè)配對是來(lái)自于檢查流程生成的配對或者在當前檢查列表的配對，它也可以被添加到有效列表中（VALID LIST）。agent為每個(gè)媒體流維護此列表狀態(tài)。在ICE處理流程啟動(dòng)時(shí)，這個(gè)列表是為空狀態(tài)，檢查流程開(kāi)始執行后在列表中逐漸增加配對，最后生成一個(gè)有效候選配對。

　　Agent經(jīng)常也會(huì )遇到一些特殊狀態(tài)-配對不在任何檢查列表中。為什么會(huì )出現這樣的情況呢？我們可以回顧一下這樣的情景，檢查列表有一對配對，其本地候選地址從來(lái)就不是一個(gè)反射候選地址。這種配對已經(jīng)獲得了它們的本地候選地址（這些地址已經(jīng)轉換成了服務(wù)器端反射候選地址的基準地址），如果這些配對重疊的話(huà)，需要對這些配對進(jìn)行過(guò)濾篩選處理。當針對STUN檢查的響應返回時(shí)，如果兩個(gè)agent之間存在一個(gè)NAT時(shí)，映射地址將會(huì )是一個(gè)反射地址。這種情況下，有效配對將有一個(gè)本地候選地址，這個(gè)地址不能匹配檢查列表中的配對的任何候選地址。

　　如果一對配對不在任何檢查列表中的話(huà)，還要首先進(jìn)行關(guān)于優(yōu)先級的計算處理。Agent將會(huì )為此配對計算優(yōu)先級。優(yōu)先級計算基于每個(gè)候選地址優(yōu)先級，其計算方式根據構建檢查列表的流程來(lái)進(jìn)行。本地候選地址的優(yōu)先級基于其類(lèi)型來(lái)決定。如果它不是peer reflexive，優(yōu)先級等同于SDP中候選地址指示的優(yōu)先級。如果它是peer reflexive，優(yōu)先級等同于agent完成的綁定請求中的PRIORITY屬性值。遠端候選地址的優(yōu)先級來(lái)自于對端peer的SDP中。如果沒(méi)有出現遠端候選地址，檢查流程必須啟動(dòng)一個(gè)triggered check來(lái)生成一個(gè)遠端候選地址。這種情況下，優(yōu)先級來(lái)自于triggered check完成的綁定請求中的PRIORITY屬性值。然后，這個(gè)有效配對被添加到有效列表中（VALID LIST）。

　　完成有效配對的構建，agent還要進(jìn)行第三步處理流程。這個(gè)步驟就是更新有效配對的狀態(tài)。Agent設置配對狀態(tài)，這個(gè)狀態(tài)是一個(gè)生成檢查成功的流程。這里一定要注意，作為一種響應結果，這里的配對（生成檢查流程）和構建有效配對是不同的處理方式（前面介紹過(guò)）。檢查的成功可能引起其他檢查的狀態(tài)也發(fā)生改變。Agent必須按照以下兩個(gè)步驟來(lái)執行：

　　如果檢查列表是在活動(dòng)狀態(tài)，agent修改檢查列表中所有封凍狀態(tài)的配對（它們的foundation匹配了有效列表中等待狀態(tài)的配對的foundation值）。

　　如果檢查列表是封凍狀態(tài)，并且在檢查列表中至少有一對配對，它的foundation匹配了有效列表的配對的foundation，在檢查列表中所有配對中，如果其foundation匹配了有效列表中的一對配對的foundation的話(huà)，所有列表中配對的狀態(tài)會(huì )設置為等待狀態(tài)。這樣的處理結果會(huì )導致檢查列表變?yōu)榛顒?dòng)狀態(tài)，ordinary checks開(kāi)始為其工作。具體細節查閱筆者歷史文檔中的定時(shí)檢查設置。

　　如果檢查列表是封凍狀態(tài)，并且檢查列表中沒(méi)有配對，它的foundation匹配有效列表中的配對的foundation的話(huà)，agent將執行以下處理流程，agent將會(huì )對所有的配對分組設置，所有配對有同樣的foundation，并且，針對每個(gè)組設置，具有最低component ID的則設置其配對狀態(tài)為等待狀態(tài)，如果有一個(gè)以上這樣的配對的話(huà)，則啟用最高優(yōu)先級的配對。

　　Agent完成了更新配對狀態(tài)以后，最后agent將會(huì )執行第四步進(jìn)行更新推薦配對處理。如果agent是一個(gè)被控方agent，它已經(jīng)在綁定請求中包含了USE- CANDIDATE屬性的話(huà)，從check生成的有效配對已經(jīng)有一個(gè)推薦配對設置flag，這個(gè)設置為true狀態(tài)。如果此配對的優(yōu)先級在所有標識的配對中具有最高的優(yōu)先級，這個(gè)標識則表示此媒體流或所有媒體流將使用這一對有效配對。如果agent是一個(gè)主控方agent，這個(gè)響應可能是triggered check的結果，這個(gè)triggered check在響應中返回到請求，此請求自己包含一個(gè)USE-CANDIDATE屬性。這樣的情況就是一個(gè)更新推薦配對示例，它可能導致對這個(gè)配對（這個(gè)配對是從原始請求學(xué)習獲得）進(jìn)行推薦flag設置。

　　以上介紹了失敗響應和成功響應的處理。在處理響應的流程中，除了對失敗響應和成功響應進(jìn)行處理以外，還要對檢查列表和定時(shí)器更新進(jìn)行處理。無(wú)論檢查是否是成功還是失敗，最后事務(wù)完成需要更新檢查列表和定時(shí)器的狀態(tài)。如果所有在檢查列表中的配對是失敗或者成功的狀態(tài)：

　　如果在檢查列表中沒(méi)有任何配對在封凍或者等待狀態(tài)的話(huà)，這個(gè)檢查列表則不再認為是活動(dòng)的檢查列表，并且針對ordinary checks，檢查列表不會(huì )在定時(shí)器計算中計入N的值。這里N是指活動(dòng)檢查列表數量。具體就是流程，讀者可以查閱筆者上一篇歷史文檔關(guān)于設定定時(shí)檢查的討論。

　　本章節重點(diǎn)介紹了關(guān)于ICE連接檢查中的STUN客戶(hù)端的處理流程。為了避免讓讀者引起歧義，方便讀者閱讀，筆者將STUN服務(wù)器端處理流程獨立分為另外一篇文章發(fā)布，關(guān)于STUN服務(wù)器端的處理流程將在下一篇文章中加以介紹。STUN服務(wù)器端主要流程包括兩個(gè)場(chǎng)景的處理流程：首先是關(guān)于全場(chǎng)景部署agent的其他額外步驟處理（檢測和修復角色沖突，計算映射地址，通過(guò)學(xué)習獲得peer反射候選地址，Triggered Checks討論和更新推薦配對標識），然后是關(guān)于輕量級部署agent的其他額外步驟處理。

　　https://www.rfc-editor.org/rfc/rfc5389https://www.rfc-editor.org/rfc/rfc8489https://www.rfc-editor.org/rfc/rfc5766https://ir.nctu.edu.tw/bitstream/11536/43505/1/655201.pdfhttps://www.cisco.com/c/en/us/td/docs/solutions/PA/ICE/icepa125.htmlhttps://dev.w3.org/2011/webrtc/editor/archives/20130830/webrtc.html