針對全場景部署agent的處理流程中，關于ICE結束的流程涉及了推薦配對和狀態(tài)機更新兩個部分的內容。其中，推薦配對是由被控方agent產生。接下來，筆者會繼續(xù)討論推薦配對的處理流程。

　　剛才筆者已經提到，推薦配對是由被控方產生的。ICE通過Regular Nomination（正常推薦方式）或Aggressive Nomination（主動推薦方式）來選擇推薦配對。選擇何種方式對推薦配對進行算法處理，取決于對端pper的部署場景。如果對端peer支持的是一個輕量級部署場景，agent必須使用Regular Nomination算法來處理。如果對端peer使用了ice-options屬性（ICE options），agent不能理解此選項的話，agent必須使用Regular Nomination算法。如果對端peer支持全場景部署，并且沒有使用任何ICE選項或者使用了ICE選項（但是，agent可以理解），agent可以選擇使用Regular Nomination或者Aggressive Nomination算法。但是，因為Regular Nomination的穩(wěn)定性比Aggressive Nomination要好，所以，RFC5245規(guī)范推薦使用Regular Nomination算法。下面，筆者分別對這兩種算法進行完整介紹。

　　圖片來自于互聯(lián)網

　　當推薦配對使用Regular Nomination時，agent會讓一些檢查流程完成處理，在檢查的每個流程中會忽略掉USE-CANDIDATE屬性。針對一個媒體流構件來說，一旦一個或多個檢查成功完成，成功檢查完成后會生成有效配對，有效配對然后添加到有效列表中。Agent會讓檢查繼續(xù)執(zhí)行，直到檢查遇到某些評判標準，然后根據某些評判標準選擇有效配對。停止檢查的評判標準和評估有效配對標準完全取決于邏輯優(yōu)化本身自己。

　　當被控方agent選擇了一對有效配對時，它會重復這個生成有效配對的檢查，并且這次使用USE-CANDIDATE屬性。因為前面的檢查是成功的，所以，理論上講，這個檢查應該也是一個成功的檢查。針對檢查的邏輯處理方式會對配對增加一個推薦標識（nominated flag），并且僅支持這個配對。因此，針對每個媒體構件來說，在有效列表中僅有一個單個支持了推薦標識配對，并且，當檢查列表的狀態(tài)切換到完成狀態(tài)后，ICE會選擇正確配對來針對媒體構件發(fā)送和接收媒體流。根據以上介紹，讀者可以看出，因為agent可以控制檢查停止和檢查的評判標準，因此，Regular Nomination具有更大的靈活性。這里只有一個要求，agent最后選擇一個配對或者只能選擇一個候選配對，然后針對此配對（支持USE-CANDIDATE屬性）生成一個檢查。通過增加拓展支持，Regular Nomination同時提高了ICE的適應能力，可以支持多種部署場景的變化。Regular Nomination具有更高的穩(wěn)定性，它可以允許雙方agent通過單個配對實現(xiàn)媒體支持，無需其他臨時選項支持（Aggressive Nomination需要臨時選項支持）。但是，Regular Nomination也有其缺點，因為Regular Nomination需要額外檢查完成，因此，Regular Nomination肯定會增加處理時延。通過以上內容的介紹，筆者描述了Regular Nomination算法的處理方式，接下來，筆者介紹一下Aggressive Nomination算法的使用方式。

　　當使用Aggressive Nomination算法時，在agent發(fā)生的每個檢查中，被控方agent會包含一個USE-CANDIDATE屬性，針對一個媒體構件的檢查中，一旦第一個檢查是成功的，這個配對就會被添加到有效列表中，然后設置一個推薦標識。在有效列表中，所有構件的配對都設置了推薦標識后，媒體開始通過最高優(yōu)先級的推薦標識配對進行傳輸。但是，因為agent在所有的檢查中都包含了USE-CANDIDATE屬性，在所有的檢查中，有可能部分其他的檢查還沒有完成，這樣就會引起其他有效配對會產生自己的推薦標識設置。因為，ICE總是從有效列表中選擇最高優(yōu)先級推薦標識的候選配對來進行媒體傳輸。因此，當ICE檢查完成時，已選擇的配對可能實際上暫時發(fā)生了修改，這樣就會導致一系列的臨時選擇作為一個緩沖（三秒延遲規(guī)則，后面講到），直到ICE檢查穩(wěn)定后，這樣的狀態(tài)才能結束。因為這個問題，因此，相對于Regular Nomination算法來說，Aggressive Nomination缺乏一定的穩(wěn)定性。但是它不會增加檢查延時。

　　無論是對于主控方agent還是被控方agent來說，ICE的處理狀態(tài)取決于在有效列表中標識候選配對的當前狀態(tài)和檢查列表的狀態(tài)。任何時間內，以下五種場景可能發(fā)生在這些處理狀態(tài)中�，F(xiàn)在，我們具體介紹一下這五種可能發(fā)生的場景。

　　對媒體流來說，如果在有效列表中沒有已設推薦標識的配對，并且檢查列表狀態(tài)是正在運行中，ICE處理將會繼續(xù)執(zhí)行。

　　對媒體流來說，如果在有效列表中至少有一對已設推薦標識的配對，并且檢查列表狀態(tài)是正在運行中，則繼續(xù)進行以下處理流程：

　　Agent設置所有的ICE處理狀態(tài)是完成狀態(tài)。

　　如果agent是正在處于被控狀態(tài)，此agent會為每個媒體流的每個構件檢查最高優(yōu)先級已標識的候選配對。如果它們中的任何候選配對不同于在最近offer/answer交互消息在的默認候選配對，被控方agent必須生成一個更新的offer。具體的生成方式根據后續(xù)offer/answer交互模式的處理流程進行。

　　如果被控方agent正在使用Aggressive Nomination，當配對選擇時，它可能導致多個更新offers。Agent可以延遲發(fā)送此更新的offer，通過一定的時間設置進行控制（RFC5245規(guī)范建議設置為一秒鐘），這個時間可以保證其已選配對進入穩(wěn)定狀態(tài)。

　　如果檢查列表的狀態(tài)是失敗狀態(tài)，ICE將不能為完成針對媒體流的處理。正確的處理方式依賴于對其他媒體流的檢查列表狀態(tài)：

　　針對輕量級部署場景agent來說，ICE結束流程相對比較直接。這里有兩個情況需要注意：

　　ICE結束處理會給agent帶來一個后續(xù)影響，agent能夠清除任何已分配的候選地址（ICE沒有使用這些候選地址）。關于清除已分配候選地址的處理方式，筆者在本文章的后續(xù)部分介紹。

　　如果對端peer是全部署場景的話，這種情況下，agent將會收到peer的連接檢查。當agent已經收到來一個連接檢查，這個檢查中包含了針對一個媒體流的每個構件所支持的USE-CANDIDATE屬性，此媒體流的ICE處理狀態(tài)將要從正在運行狀態(tài)遷移到完成狀態(tài)。當針對所有媒體流的ICE處理狀態(tài)是完成狀態(tài)的話，所有ICE處理狀態(tài)都是完成狀態(tài)。輕量級部署從來不自己決定針對媒體流的ICE流程失敗處理，而是寧愿讓全場景部署的agent來決定。在后續(xù)的offer中，針對失敗的媒體流，全場景部署將做出決定，移除或重新啟動這些失敗的媒體流。

　　如果對端peer是輕量級peer的話，ICE結束處理的流程相對比較復雜一些。一旦offer/answer交互模式完成后，雙方agent都會檢查它們的候選地址和它的peer的候選地址。針對每個媒體流，每個agent將會使用自己候選地址和對端peer的候選地址進行配對處理。當它們具有同樣的component，使用同樣的傳輸協(xié)議（RFC5245使用UDP傳輸協(xié)議），并且來自于同一IP地址類型（IPv4或IPV6），那么這兩個候選地址就會配對。在生成配對后，針對每個媒體流構件中的配對數量有兩種處理方式：

　　如果在每個媒體構件中，有一個單個配對的話，此配對會添加到有效列表中。如果一個媒體的所有構件只有一個配對的話，針對此媒體流的ICE處理狀態(tài)將會設置為完成狀態(tài)。如果所有媒體流的ICE處理狀態(tài)是完成狀態(tài)的話，所有ICE處理狀態(tài)將會設置為完成狀態(tài)。這種部署環(huán)境經常會發(fā)生在IPv4的網絡環(huán)境中。

　　如果在每個構件中，有多于一個以上的配對的話，需要執(zhí)行以下幾個步驟：

　　當offer發(fā)送以后，agent一定不能更新ICE處理狀態(tài)。針對所有媒體流，如果此后續(xù)offer完成處理，主控方agent必須修改ICE處理流程狀態(tài)為完成狀態(tài)，并且設置所有ICE處理狀態(tài)為完成狀態(tài)。主控方agent的狀態(tài)設置則基于輕量級部署場景的流程來進行處理。

　　在ICE結束處理的流程中，包括兩種對后選地址的封凍處理。一種是全場景部署中封凍處理，另外一種是輕量級的部署場景封凍處理。接下來，筆者分別對其流程進行說明。

　　首先介紹全場景中關于封凍處理的流程。ICE結束處理的流程要求agent繼續(xù)監(jiān)聽STUN請求，一旦對其媒體流的處理完成后，繼續(xù)對媒體流生成triggered checks。RFC5245介紹了一種規(guī)則，規(guī)則描述了當agent處于安全狀態(tài)時，它在一個候選地址（ICE沒有選擇此候選地址，然后釋放候選地址）終止發(fā)送或接收檢查。

　　當SIP網絡中使用了ICE，并且offer被經過分叉處理發(fā)送到多個接收方時，ICE將會使用同樣的本地候選地址并行和每個自己的answer進行處理。對所有使用那些候選地址來傳輸媒體流的peers來說，一旦ICE處理流程狀態(tài)達到完成狀態(tài)，agent應該等待另外三秒鐘，然后agent可以終止對檢查的響應，或在那個候選地址生成一個triggered checks。Agent可以在那個等待時間釋放候選地址。注意，服務器端反射候選地址的封凍處理從來不會被明確聲明，keepalive的缺失會啟動封凍處理流程發(fā)生。三秒延遲的規(guī)則策略可以處理如下場景，具體來說，ICE已經完成后，agent使用了aggressive nomination算法，然后對已選配對進行快速修改。

　　輕量級部署場景中ICE結束處理相對比較簡單。對所有使用那些候選地址來傳輸媒體流的peers來說，一旦ICE處理流程狀態(tài)達到完成狀態(tài)，輕量級部署場景可以釋放任何沒有被ICE選擇的候選地址。

　　完成了關于ICE的討論以后，筆者將進一步討論關于后續(xù)offer/answer交互中的offer生成，answer接收，更新offer等細節(jié)。

　　https://www.rfc-editor.org/rfc/rfc6724

　　https://www.rfc-editor.org/rfc/rfc3484

　　https://www.rfc-editor.org/rfc/rfc5245.html

　　https://datatracker.ietf.org/meeting/93/materials/slides-93-mmusic-3

　　https://bugzilla.mozilla.org/show_bug.cgi?id=1034964