Agent收到初始offer以后，首先，它需要驗證ICE的支持能力。對于每個(gè)在SDP中收到的媒體流來(lái)說(shuō)，如果媒體流的每個(gè)構件的默認目的地地址出現在了候選地址屬性中，agent將會(huì )根據RFC5245規范中ICE的處理流程來(lái)進(jìn)行處理。如果我們進(jìn)一步做具體理解的話(huà)，我們可以參考RTP的處理方式來(lái)說(shuō)明。例如，使用RTP時(shí)，在c行和m=行的IP地址和端口出現在了候選地址屬性參數中；使用RTCP時(shí)，RTCP值也會(huì )出現在候選地址屬性中。如果前面所說(shuō)的這個(gè)條件不成立，或者這些媒體構件沒(méi)有出現在候選地址屬性中的話(huà)，agent必須按照另外一個(gè)流程來(lái)處理SDP（RFC3264）值，而無(wú)需按照ICE的處理機制來(lái)處理。這個(gè)流程就是我們在前面文章中所介紹的關(guān)于SIP針對offer/answer交互模式來(lái)處理。讀者可以查看歷史文檔來(lái)回顧筆者介紹的相關(guān)基礎內容。如果按照RFC3264處理的話(huà)，讀者也需要注意幾個(gè)例外條件：

　　所有agent必須遵從RFC5245-10中的會(huì )話(huà)存活保持流程。

　　如果agent沒(méi)有根據RFC5245 ICE的處理流程處理的話(huà)，是因為有a=候選地址屬性，但是這些a=候選屬性沒(méi)有匹配媒體流的默認目的地地址，agent在其answer消息中必須包括一個(gè)a=icemismatch屬性（無(wú)匹配）。

　　如果默認候選地址是一個(gè)從TURN服務(wù)器學(xué)習獲得的轉發(fā)地址，agent必須在TRUN服務(wù)器端創(chuàng )建一個(gè)授權許可，這個(gè)許可支持SDP中收到的，從對端的peer學(xué)習到的IP地址。大家需要注意，如果權限設置有問(wèn)題的話(huà)，對端發(fā)過(guò)來(lái)的初始數據包將會(huì )丟失。

　　在上一篇文章中，筆者介紹了主控agent和被控方agent的角色。在會(huì )話(huà)中，每個(gè)agent需要充當一個(gè)角色來(lái)執行不同的操作流程。主控方負責選擇最終候選配對和被控方進(jìn)行通信，如果是全部署環(huán)境下的agent，這表示ICE使用挑選的候選配對對每個(gè)媒體流進(jìn)行傳輸，并且，當agent需要時(shí)，可基于ICE的選擇生成更新的offer消息。如果是輕量級的部署環(huán)境中的agnet，選定為主控方agent表示選擇了候選地址配對，這個(gè)候選配對是基于offer和answer消息中的配對（在IPv4中僅有一對），并且，當agent需要時(shí)，生成一個(gè)更新的offer消息來(lái)反映這個(gè)選擇。被控方agent被告知使用的候選配對來(lái)傳輸媒體流，并且針對這個(gè)單個(gè)信息不會(huì )生成一個(gè)更新offer。下面，筆者將討論決定雙方角色的規則和處理流程對雙方的的影響。關(guān)于決定雙方角色的規則和其流程的影響，事實(shí)上，這取決于雙方agent所處的部署環(huán)境，這里有三種不同的部署環(huán)境需要討論：雙方都在全部署場(chǎng)景，雙方各自在全部署場(chǎng)景/輕量級部署場(chǎng)景，雙方都在輕量級部署場(chǎng)景。

　　雙方都在全部署場(chǎng)景中，如果一個(gè)agent生成了一個(gè)offer消息，并且啟動(dòng)了ICE處理流程，這個(gè)agent必須扮演一個(gè)主控方agent的角色。另外一側agent則必須扮演被控方角色。雙方agent將會(huì )構建檢查列表，運行ICE狀態(tài)機和連接檢查的流程。主控方將會(huì )根據全部署場(chǎng)景流程執行處理邏輯，挑選候選配，ICE根據這些候選配對提供進(jìn)一步的選擇，最后雙方agent通過(guò)更新offer來(lái)更新或者結束ICE處理流程。當然，在實(shí)際部署場(chǎng)景中，不排除一些特殊使用環(huán)境，例如因為其他通信因素，雙方的角色認定發(fā)生沖突。雙方agnet錯誤地認為自己是主控方或者自己是被控方。因此，為了避免類(lèi)似情況的發(fā)送，每個(gè)agent必須選擇一個(gè)任意號碼，RFC5245規范稱(chēng)之為tie-breaker，在連接檢查中使用此數值檢測修復這種情況，其取值范圍一律發(fā)布在0和（2**64） - 1之間（它是一個(gè)64位的正整數）。

　　雙方一方是全部署場(chǎng)景agent，另外一方是輕量級部署場(chǎng)景agent中，全部署場(chǎng)景的agent必須扮演主控方agent的角色，輕量級agent則必須扮演被控方agent的角色。全部署agent將會(huì )構建檢查列表，運行ICE狀態(tài)機和生成連接檢查。主控方將會(huì )根據全部署場(chǎng)景流程執行處理邏輯，挑選候選配對，ICE根據這些候選配對提供進(jìn)一步的選擇。輕量級agent將會(huì )監聽(tīng)連接檢查，接收響應檢查消息，按照輕量級部署的結束ICE處理流程，最后對ICE進(jìn)行結束處理。因為雙方的角色不同，從某種程度來(lái)說(shuō)，主控角色一般都是一直處于運行狀態(tài)。因此，對輕量級部署agent來(lái)說(shuō)，針對每個(gè)媒體流來(lái)說(shuō)，ICE處理狀態(tài)被認為是運行狀態(tài)，所有ICE流程也是運行狀態(tài)。

　　Agent雙方都是輕量級部署的agent的話(huà)，如果一個(gè)agent生成了offer消息，并且啟動(dòng)了ICE處理流程，這個(gè)agent必須扮演一個(gè)主控方agent的角色。另外一側agent則必須扮演被控方角色。這種環(huán)境中，雙方從來(lái)都不會(huì )發(fā)送連接檢查。準確地說(shuō)，一旦雙方的offer/answer交互模式完成以后，每個(gè)agent將執行ICE結束處理流程，它們無(wú)需經(jīng)過(guò)連接檢查的流程。和第一種場(chǎng)景中所描述的一樣，同樣的角色沖突問(wèn)題也可能出現在雙方都是輕量級部署agent的環(huán)境中。它們都可能認為自己是主控方agent或者被控方agent。這種情況下的處理方式和全場(chǎng)景部署中的角色決定的處理方式不同。輕量級部署環(huán)境中角色沖突時(shí)，雙方agent通過(guò)在信令中承載的offer/answer交互，和交互消息中所支持的檢測能力來(lái)確定雙方角色。對輕量級部署agent來(lái)說(shuō)，針對每個(gè)媒體流來(lái)說(shuō)，ICE處理狀態(tài)被認為是運行狀態(tài)，所有ICE流程也是運行狀態(tài)。

　　在會(huì )話(huà)中，一旦雙方角色確定以后，除非ICE重新啟動(dòng)，否則，它們將一直持續充當各自的角色。補充說(shuō)明，因為ICE重新啟動(dòng)以后，雙方需要重新決定各自的角色，如果是全部署場(chǎng)景agent的話(huà)，它們需要重新對tie-breaker賦值計算。

　　關(guān)于針對候選地址的采集處理流程，answerer應答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細地做出了說(shuō)明。用戶(hù)可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級部署的要求等內容。根據RFC5245的推薦，提供方收到offer，早于對用戶(hù)提醒之前馬上執行采集流程。當agent啟動(dòng)時(shí)，這樣的候選地址采集方式就可能開(kāi)始。

　　關(guān)于針對候選地址的排序處理流程，answerer應答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細地做出了說(shuō)明。用戶(hù)可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級部署的要求等內容。

　　關(guān)于針對候選地址的默認候選地址選擇的處理流程，answerer應答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細地做出了說(shuō)明。用戶(hù)可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級部署的要求等內容。

　　關(guān)于針對SDP解碼的處理流程，answerer應答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中針對全部署場(chǎng)景和輕量級部署場(chǎng)景的規定已經(jīng)非常詳細地做出了說(shuō)明。用戶(hù)可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級部署的要求等內容。

　　構建檢查列表是由全部署場(chǎng)景來(lái)實(shí)現的，如果是輕量級的部署場(chǎng)景，無(wú)需構建檢查列表。因為offer/answer交互模式的使用，在媒體使用的過(guò)程中需要一個(gè)檢查列表。為了對媒體流構建一個(gè)檢查列表，agent需要經(jīng)過(guò)幾個(gè)必要的步驟來(lái)構建檢查列表，agent需要經(jīng)過(guò)的步驟是：構建候選地址配對，計算候選配對優(yōu)先級和排序，優(yōu)選配對，最后計算配對狀態(tài)。接下來(lái)，筆者將分別討論這四個(gè)主要的步驟。

　　首先，為了實(shí)現對媒體流的支持，agent選擇自己本地候選地址和從對端peer收到的候選地址進(jìn)行配對處理。這里，本地候選地址稱(chēng)之為L(cháng)OCAL CANDIDATES，遠端的候選地址稱(chēng)之為REMOTE CANDIDATES。選擇過(guò)程中，agent同時(shí)還要考慮安全的問(wèn)題，為了防止選擇的地址被攻擊，agent可以設置從offer或answer中接收候選地址的數量。關(guān)于STUN被攻擊的可能性討論，請讀者參考RFC5245-18，后期文章中我們將討論這個(gè)話(huà)題，現在不做討論。如果本地候選地址和遠端候選地址配對成功的話(huà)，它們必須具有相同的component ID，和同樣的IP地址版本。當然，實(shí)際環(huán)境中，本地候選地址和遠端候選地址也完全可能存在不匹配或者匹配不成功的可能，或者，遠端候選地址和本地候選地址匹配不成功的可能。有時(shí)也可能發(fā)生這樣的問(wèn)題，例如，針對一個(gè)媒體流來(lái)說(shuō)，agent沒(méi)有包含候選地址來(lái)支持此媒體流的所有構件模塊。如果是這樣的情況的話(huà)，此媒體流的構件數量就會(huì )受到影響而減少，并且會(huì )認為這個(gè)數量等于雙方agent所要求的構件最低數量，此最低數量值針對媒體流的所有component構件，并且來(lái)源于雙方agent所提供的最大component ID（關(guān)于ID取值范圍讀者可參考前面的介紹和歷史文檔）。

　　除了上面所介紹的一些情況以外，還有幾個(gè)比較特殊的情況和讀者說(shuō)明。在涉及到RTP/RTCP的使用場(chǎng)景中有可能發(fā)生這樣的情況，一方agent提供了RTCP的候選地址，但是對端可能沒(méi)有提供類(lèi)似地址。有時(shí)，offer消息提供方可在同一端口多路復用RTP/RTCP數據，并且通過(guò)SDP屬性中指示了這樣的實(shí)現方式（多路復用RTP/RTCP參考RFC5761-5和RFC8035）。但是，如果answerer執行了多路復用RTP/RTCP的話(huà)，offerer則不知道answerer執行了這樣的流程，offerer就會(huì )按照默認的設置方式使用各自獨立的RTP和RTCP，這樣處理的結果就會(huì )導致每個(gè)媒體流中在offer消息中包含兩個(gè)components。answerer方執行了多路復用RTP/RTCP，對每個(gè)候選地址來(lái)說(shuō)，它將僅包含單個(gè)component。因此，此component將是RTP/RTCP mux的合并值。如果此候選地址只有單個(gè)component的話(huà)，ICE結束執行候選地址配對。毫無(wú)疑問(wèn)，如果配對中本地候選地址和遠端候選地址都是默認候選地址時(shí)，這個(gè)候選配對被認為是默認的候選配對。

　　如果agent雙方不是ICE感知的agent的話(huà)，媒體流構件使用此默認候選配對傳輸媒體流。讀者可以參考以下示例來(lái)理解check list（檢查列表）核心概念和與其他模塊之間的關(guān)系。

　　構建候選地址配對完成以后，需要進(jìn)行后續地址配對的優(yōu)先級計算。優(yōu)先級計算是根據以下格式來(lái)計算的。其中，G表示主控方agent提供的候選優(yōu)先級，D表示被控制方提供的候選地址優(yōu)先級。這里，G>D?1:0是一個(gè)表達式，如果G大于D，則取值為1，否則為0。

　　pair priority = 2 ^ 32 *MIN（G,D） + 2 *MAX（G,D） + （G > D?1:0）

　　關(guān)于以上優(yōu)先級的計算，很多開(kāi)源項目有類(lèi)似的處理方式，讀者可以參考一些開(kāi)源項目來(lái)做進(jìn)一步了解。以下一段代碼是一個(gè)配對計算源代碼示例，讀者可以參考：

　　// PairPriority computes Pair Priority as in RFC 8445  func PairPriority（controlling, controlled int） int64 {

　　var （

　　g = int64（controlling）

　　d=int64（controlled） ）

　　// pair priority = 2^32*MIN（G,D） + 2*MAX（G,D） + （G>D?1:0） v := （1<<32）*min（g, d） + 2*max（g, d）

　　if g > d {

　　v++ }

　　return v }

　　https://github.com/gortc/ice/blob/master/pair.go

　　一旦優(yōu)先級被設定以后，agent就會(huì )按照順序對候選地址配對進(jìn)行排序。排序的規則按照優(yōu)先級順序遞減的方式進(jìn)行。如果兩組候選地址配對有相同的優(yōu)先級，它們兩組配對的實(shí)現可以任意排序。

　　獲得了候選地址配對排序以后，此優(yōu)選候選地址會(huì )生成一個(gè)排序后的配對列表。ICE將會(huì )按照排序列表逐一進(jìn)行連接檢查。在每個(gè)檢查流程將會(huì )涉及發(fā)送請求的流程，agent需要從本地候選地址發(fā)送檢查請求到遠端候選地址。這里注意，因為agent不能直接從反射地址發(fā)送請求，它僅能從base基準地址發(fā)送請求，所以agent需要通過(guò)排序后的配對列表來(lái)發(fā)送請求。對每個(gè)配對來(lái)說(shuō)，如果本地候選地址是一個(gè)反射地址的話(huà)，base基準地址必須替換這個(gè)反射候選地址。一旦替換流程完成后，agent必須過(guò)濾或篩選此列表。過(guò)濾配對列表的流程通過(guò)移除配對的方式來(lái)實(shí)現。具體來(lái)說(shuō)，如果它（需要移除的配對）的本地候選地址/遠端候選地址和優(yōu)先級列表中較高優(yōu)先級的一對配對相同的話(huà)，則需要移除配對相同的較低優(yōu)先級的配對。

　　另外，為了安全的考慮，防止STUN服務(wù)器被攻擊，agent必須限制連接檢查數量，在一定的數值設置環(huán)境中，agent的檢查將會(huì )覆蓋所有連接列表的地址，這個(gè)特定數值必須是可配置的數值。規范RFC5245推薦默認數值是100。候選配對列表一直保持低于100的限定設置，一些低優(yōu)先級的候選配對將被強制丟棄。在可能的情況下，RFC5245推薦盡量使用比較低的設置限定，在實(shí)際生產(chǎn)環(huán)境中也可能看到一些用戶(hù)針對配對檢查設置了最大檢查限定。要求支持可配置的限定設置也是為系統提供了一個(gè)工具，如果發(fā)現問(wèn)題以后，可以通過(guò)此限定值來(lái)排查問(wèn)題。

　　完成了候選配對地址的挑選以后，檢查列表需要進(jìn)行狀態(tài)計算。每個(gè)候選配對支持了一個(gè)foundation和一個(gè)state（狀態(tài)）。實(shí)際上，這里的foundation是合并了本地候選地址的foundation和遠端的候選地址的fundation而生成的一個(gè)新的fundation。一旦開(kāi)始計算foundation時(shí)，每個(gè)配對將會(huì )設定一個(gè)狀態(tài)值，根據檢查結果的不同，候選配對需要經(jīng)過(guò)五個(gè)可能或潛在的狀態(tài)計算（歷史文章也有介紹這五個(gè)計算步驟）。

　　ICE開(kāi)始運行時(shí)，一個(gè)候選配對將遷移到以下任何一種狀態(tài)。筆者再次重復一次每個(gè)狀態(tài)的任務(wù)然后介紹具體流程處理：

　　在檢查列表中的每個(gè)候選配對的初始狀態(tài)需要經(jīng)過(guò)一個(gè)狀態(tài)計算。其狀態(tài)計算需要按序經(jīng)過(guò)以下幾個(gè)步驟：

　　這里有兩個(gè)特定的列表稱(chēng)謂需要讀者注意。其中檢查列表中的一部分配對會(huì )進(jìn)入等待狀態(tài)，另外一部分則進(jìn)入到封凍狀態(tài)。如果檢查列表中至少有一對配對是在等待狀態(tài)的，這樣的列表稱(chēng)之為活動(dòng)檢查列表。如果檢查列表中所有配對都是封凍狀態(tài)的，這樣的列表稱(chēng)之為封凍檢查列表。

　　除了檢查列表中的配對檢查有狀態(tài)存在，檢查列表自己本身也關(guān)聯(lián)一個(gè)狀態(tài)，針對正在工作的媒體流，這個(gè)狀態(tài)用來(lái)捕捉ICE檢查的狀態(tài)。檢查列表具有三種狀態(tài)：

　　作為一個(gè)offer/answer交互的結果，檢查列表首先構建的就會(huì )被ICE遷移到運行狀態(tài)中。ICE處理流程覆蓋所有的媒體流過(guò)程中，因此，ICE也和這個(gè)流程本身有一個(gè)關(guān)聯(lián)綁定的狀態(tài)。當ICE運行時(shí)，這個(gè)狀態(tài)等于運行狀態(tài)。當ICE處理流程完成后，這個(gè)狀態(tài)將是完成狀態(tài)，如果ICE處理流程失敗的話(huà)，這個(gè)狀態(tài)就是失敗狀態(tài)。關(guān)于以上幾個(gè)狀態(tài)之間切換的規則筆者將在定時(shí)檢查的討論中做更多說(shuō)明。

　　前面我們一直在討論關(guān)于check的流程，check是由全部署場(chǎng)景生成的，所以，如果agent是輕量級的部署方式的話(huà)，可以跳過(guò)此內容討論。Agent執行兩種check，一種是ordinary checks，另外一種是triggered checks。兩種check都是由一個(gè)定時(shí)器來(lái)控制，針對媒體流數據，定時(shí)器會(huì )周期性地觸發(fā)check生成事件。

　　除了定時(shí)器以外，agent也會(huì )維護一個(gè)先進(jìn)先出的隊列，這個(gè)隊列稱(chēng)之為triggered check隊列，隊列維護候選配對，如果有check的機會(huì )的話(huà)，這個(gè)隊列將會(huì )發(fā)送配對進(jìn)行檢查。當定時(shí)器觸發(fā)以后，agent將會(huì )從triggered checks隊列頂部移除一個(gè)配對，對這個(gè)配對執行連接檢查，最后把這對候選配對的狀態(tài)設置為正在處理的狀態(tài)（In-Progress）。如果在triggered checks隊列中沒(méi)有配對的話(huà)，agent將會(huì )發(fā)送ordinary checks。

　　一旦完成構建檢測列表計算的流程，agent將會(huì )針對每個(gè)active check list設置一個(gè)定時(shí)器。每Ta*N秒觸發(fā)一次定時(shí)器，這里的N是active check list的數量（初始階段，至少有一個(gè)active check list）。Ta和RTO這兩個(gè)定時(shí)器會(huì )在未來(lái)的討論中加以介紹，這里不再展開(kāi)討論。Ta乘以N將允許整個(gè)check的吞吐量發(fā)布到所有active check list中。在實(shí)際部署環(huán)境中，這個(gè)定時(shí)器觸發(fā)的頻率可以低于上面的設置，同時(shí)，也應該考慮定時(shí)器傳播的問(wèn)題，盡量不要同時(shí)對每個(gè)媒體發(fā)布定時(shí)器。第一個(gè)定時(shí)器馬上觸發(fā)后，agent在這一瞬間（offer/answer交互模式已完成）執行連接檢查，然后在Ta秒后執行下一個(gè)檢查（因為在第一個(gè)定時(shí)器觸發(fā)時(shí)只有一個(gè)active check list）。

　　如果定時(shí)器觸發(fā)以后，agent沒(méi)有triggered checks需要發(fā)送的話(huà)，它必須按照以下規則選擇一個(gè)ordinary checks：

　　在接下來(lái)的章節中，筆者將繼續分享初始應答接收的話(huà)題（驗證ICE支持，決定角色等話(huà)題）。

　　參考資料：

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

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

　　https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidatePairStats/state

　　https://github.com/gortc/ice/blob/master/pair.go

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

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

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

　　如何使用FreeSBC，qq技術(shù)分享群：334023047