1、驗(yàn)證ICE支持能力
Agent收到初始o(jì)ffer以后，首先，它需要驗(yàn)證ICE的支持能力。對(duì)于每個(gè)在SDP中收到的媒體流來(lái)說(shuō)，如果媒體流的每個(gè)構(gòu)件的默認(rèn)目的地地址出現(xiàn)在了候選地址屬性中，agent將會(huì)根據(jù)RFC5245規(guī)范中ICE的處理流程來(lái)進(jìn)行處理。如果我們進(jìn)一步做具體理解的話，我們可以參考RTP的處理方式來(lái)說(shuō)明。例如，使用RTP時(shí)，在c行和m=行的IP地址和端口出現(xiàn)在了候選地址屬性參數(shù)中；使用RTCP時(shí)，RTCP值也會(huì)出現(xiàn)在候選地址屬性中。如果前面所說(shuō)的這個(gè)條件不成立，或者這些媒體構(gòu)件沒(méi)有出現(xiàn)在候選地址屬性中的話，agent必須按照另外一個(gè)流程來(lái)處理SDP（RFC3264）值，而無(wú)需按照ICE的處理機(jī)制來(lái)處理。這個(gè)流程就是我們?cè)谇懊嫖恼轮兴榻B的關(guān)于SIP針對(duì)offer/answer交互模式來(lái)處理。讀者可以查看歷史文檔來(lái)回顧筆者介紹的相關(guān)基礎(chǔ)內(nèi)容。如果按照RFC3264處理的話，讀者也需要注意幾個(gè)例外條件：
所有agent必須遵從RFC5245-10中的會(huì)話存活保持流程。
如果agent沒(méi)有根據(jù)RFC5245 ICE的處理流程處理的話，是因?yàn)橛衋=候選地址屬性，但是這些a=候選屬性沒(méi)有匹配媒體流的默認(rèn)目的地地址，agent在其answer消息中必須包括一個(gè)a=icemismatch屬性（無(wú)匹配）。
如果默認(rèn)候選地址是一個(gè)從TURN服務(wù)器學(xué)習(xí)獲得的轉(zhuǎn)發(fā)地址，agent必須在TRUN服務(wù)器端創(chuàng)建一個(gè)授權(quán)許可，這個(gè)許可支持SDP中收到的，從對(duì)端的peer學(xué)習(xí)到的IP地址。大家需要注意，如果權(quán)限設(shè)置有問(wèn)題的話，對(duì)端發(fā)過(guò)來(lái)的初始數(shù)據(jù)包將會(huì)丟失。
2、決定主控/被控制方角色
在上一篇文章中，筆者介紹了主控agent和被控方agent的角色。在會(huì)話中，每個(gè)agent需要充當(dāng)一個(gè)角色來(lái)執(zhí)行不同的操作流程。主控方負(fù)責(zé)選擇最終候選配對(duì)和被控方進(jìn)行通信，如果是全部署環(huán)境下的agent，這表示ICE使用挑選的候選配對(duì)對(duì)每個(gè)媒體流進(jìn)行傳輸，并且，當(dāng)agent需要時(shí)，可基于ICE的選擇生成更新的offer消息。如果是輕量級(jí)的部署環(huán)境中的agnet，選定為主控方agent表示選擇了候選地址配對(duì)，這個(gè)候選配對(duì)是基于offer和answer消息中的配對(duì)（在IPv4中僅有一對(duì)），并且，當(dāng)agent需要時(shí)，生成一個(gè)更新的offer消息來(lái)反映這個(gè)選擇。被控方agent被告知使用的候選配對(duì)來(lái)傳輸媒體流，并且針對(duì)這個(gè)單個(gè)信息不會(huì)生成一個(gè)更新offer。下面，筆者將討論決定雙方角色的規(guī)則和處理流程對(duì)雙方的的影響。關(guān)于決定雙方角色的規(guī)則和其流程的影響，事實(shí)上，這取決于雙方agent所處的部署環(huán)境，這里有三種不同的部署環(huán)境需要討論：雙方都在全部署場(chǎng)景，雙方各自在全部署場(chǎng)景/輕量級(jí)部署場(chǎng)景，雙方都在輕量級(jí)部署場(chǎng)景。
雙方都在全部署場(chǎng)景中，如果一個(gè)agent生成了一個(gè)offer消息，并且啟動(dòng)了ICE處理流程，這個(gè)agent必須扮演一個(gè)主控方agent的角色。另外一側(cè)agent則必須扮演被控方角色。雙方agent將會(huì)構(gòu)建檢查列表，運(yùn)行ICE狀態(tài)機(jī)和連接檢查的流程。主控方將會(huì)根據(jù)全部署場(chǎng)景流程執(zhí)行處理邏輯，挑選候選配，ICE根據(jù)這些候選配對(duì)提供進(jìn)一步的選擇，最后雙方agent通過(guò)更新offer來(lái)更新或者結(jié)束ICE處理流程。當(dāng)然，在實(shí)際部署場(chǎng)景中，不排除一些特殊使用環(huán)境，例如因?yàn)槠渌ㄐ乓蛩�，雙方的角色認(rèn)定發(fā)生沖突。雙方agnet錯(cuò)誤地認(rèn)為自己是主控方或者自己是被控方。因此，為了避免類似情況的發(fā)送，每個(gè)agent必須選擇一個(gè)任意號(hào)碼，RFC5245規(guī)范稱之為tie-breaker，在連接檢查中使用此數(shù)值檢測(cè)修復(fù)這種情況，其取值范圍一律發(fā)布在0和（2**64） - 1之間（它是一個(gè)64位的正整數(shù)）。
雙方一方是全部署場(chǎng)景agent，另外一方是輕量級(jí)部署場(chǎng)景agent中，全部署場(chǎng)景的agent必須扮演主控方agent的角色，輕量級(jí)agent則必須扮演被控方agent的角色。全部署agent將會(huì)構(gòu)建檢查列表，運(yùn)行ICE狀態(tài)機(jī)和生成連接檢查。主控方將會(huì)根據(jù)全部署場(chǎng)景流程執(zhí)行處理邏輯，挑選候選配對(duì)，ICE根據(jù)這些候選配對(duì)提供進(jìn)一步的選擇。輕量級(jí)agent將會(huì)監(jiān)聽(tīng)連接檢查，接收響應(yīng)檢查消息，按照輕量級(jí)部署的結(jié)束ICE處理流程，最后對(duì)ICE進(jìn)行結(jié)束處理。因?yàn)殡p方的角色不同，從某種程度來(lái)說(shuō)，主控角色一般都是一直處于運(yùn)行狀態(tài)。因此，對(duì)輕量級(jí)部署agent來(lái)說(shuō)，針對(duì)每個(gè)媒體流來(lái)說(shuō)，ICE處理狀態(tài)被認(rèn)為是運(yùn)行狀態(tài)，所有ICE流程也是運(yùn)行狀態(tài)。
Agent雙方都是輕量級(jí)部署的agent的話，如果一個(gè)agent生成了offer消息，并且啟動(dòng)了ICE處理流程，這個(gè)agent必須扮演一個(gè)主控方agent的角色。另外一側(cè)agent則必須扮演被控方角色。這種環(huán)境中，雙方從來(lái)都不會(huì)發(fā)送連接檢查。準(zhǔn)確地說(shuō)，一旦雙方的offer/answer交互模式完成以后，每個(gè)agent將執(zhí)行ICE結(jié)束處理流程，它們無(wú)需經(jīng)過(guò)連接檢查的流程。和第一種場(chǎng)景中所描述的一樣，同樣的角色沖突問(wèn)題也可能出現(xiàn)在雙方都是輕量級(jí)部署agent的環(huán)境中。它們都可能認(rèn)為自己是主控方agent或者被控方agent。這種情況下的處理方式和全場(chǎng)景部署中的角色決定的處理方式不同。輕量級(jí)部署環(huán)境中角色沖突時(shí)，雙方agent通過(guò)在信令中承載的offer/answer交互，和交互消息中所支持的檢測(cè)能力來(lái)確定雙方角色。對(duì)輕量級(jí)部署agent來(lái)說(shuō)，針對(duì)每個(gè)媒體流來(lái)說(shuō)，ICE處理狀態(tài)被認(rèn)為是運(yùn)行狀態(tài)，所有ICE流程也是運(yùn)行狀態(tài)。
在會(huì)話中，一旦雙方角色確定以后，除非ICE重新啟動(dòng)，否則，它們將一直持續(xù)充當(dāng)各自的角色。補(bǔ)充說(shuō)明，因?yàn)镮CE重新啟動(dòng)以后，雙方需要重新決定各自的角色，如果是全部署場(chǎng)景agent的話，它們需要重新對(duì)tie-breaker賦值計(jì)算。
3、候選地址采集
關(guān)于針對(duì)候選地址的采集處理流程，answerer應(yīng)答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細(xì)地做出了說(shuō)明。用戶可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級(jí)部署的要求等內(nèi)容。根據(jù)RFC5245的推薦，提供方收到offer，早于對(duì)用戶提醒之前馬上執(zhí)行采集流程。當(dāng)agent啟動(dòng)時(shí)，這樣的候選地址采集方式就可能開(kāi)始。
4、候選地址優(yōu)先級(jí)排序
關(guān)于針對(duì)候選地址的排序處理流程，answerer應(yīng)答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細(xì)地做出了說(shuō)明。用戶可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級(jí)部署的要求等內(nèi)容。
5、默認(rèn)候選地址選擇
關(guān)于針對(duì)候選地址的默認(rèn)候選地址選擇的處理流程，answerer應(yīng)答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中已經(jīng)非常詳細(xì)地做出了說(shuō)明。用戶可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級(jí)部署的要求等內(nèi)容。
6、SDP解碼
關(guān)于針對(duì)SDP解碼的處理流程，answerer應(yīng)答方和offerer提供方的處理方式是完全一樣的。筆者在前面的文章中針對(duì)全部署場(chǎng)景和輕量級(jí)部署場(chǎng)景的規(guī)定已經(jīng)非常詳細(xì)地做出了說(shuō)明。用戶可以閱讀此文章來(lái)了解全部署場(chǎng)景中的場(chǎng)景流程和輕量級(jí)部署的要求等內(nèi)容。
7、檢查列表構(gòu)建
構(gòu)建檢查列表是由全部署場(chǎng)景來(lái)實(shí)現(xiàn)的，如果是輕量級(jí)的部署場(chǎng)景，無(wú)需構(gòu)建檢查列表。因?yàn)閛ffer/answer交互模式的使用，在媒體使用的過(guò)程中需要一個(gè)檢查列表。為了對(duì)媒體流構(gòu)建一個(gè)檢查列表，agent需要經(jīng)過(guò)幾個(gè)必要的步驟來(lái)構(gòu)建檢查列表，agent需要經(jīng)過(guò)的步驟是：構(gòu)建候選地址配對(duì)，計(jì)算候選配對(duì)優(yōu)先級(jí)和排序，優(yōu)選配對(duì)，最后計(jì)算配對(duì)狀態(tài)。接下來(lái)，筆者將分別討論這四個(gè)主要的步驟。
首先，為了實(shí)現(xiàn)對(duì)媒體流的支持，agent選擇自己本地候選地址和從對(duì)端peer收到的候選地址進(jìn)行配對(duì)處理。這里，本地候選地址稱之為L(zhǎng)OCAL CANDIDATES，遠(yuǎn)端的候選地址稱之為REMOTE CANDIDATES。選擇過(guò)程中，agent同時(shí)還要考慮安全的問(wèn)題，為了防止選擇的地址被攻擊，agent可以設(shè)置從offer或answer中接收候選地址的數(shù)量。關(guān)于STUN被攻擊的可能性討論，請(qǐng)讀者參考RFC5245-18，后期文章中我們將討論這個(gè)話題，現(xiàn)在不做討論。如果本地候選地址和遠(yuǎn)端候選地址配對(duì)成功的話，它們必須具有相同的component ID，和同樣的IP地址版本。當(dāng)然，實(shí)際環(huán)境中，本地候選地址和遠(yuǎn)端候選地址也完全可能存在不匹配或者匹配不成功的可能，或者，遠(yuǎn)端候選地址和本地候選地址匹配不成功的可能。有時(shí)也可能發(fā)生這樣的問(wèn)題，例如，針對(duì)一個(gè)媒體流來(lái)說(shuō)，agent沒(méi)有包含候選地址來(lái)支持此媒體流的所有構(gòu)件模塊。如果是這樣的情況的話，此媒體流的構(gòu)件數(shù)量就會(huì)受到影響而減少，并且會(huì)認(rèn)為這個(gè)數(shù)量等于雙方agent所要求的構(gòu)件最低數(shù)量，此最低數(shù)量值針對(duì)媒體流的所有component構(gòu)件，并且來(lái)源于雙方agent所提供的最大component ID（關(guān)于ID取值范圍讀者可參考前面的介紹和歷史文檔）。
除了上面所介紹的一些情況以外，還有幾個(gè)比較特殊的情況和讀者說(shuō)明。在涉及到RTP/RTCP的使用場(chǎng)景中有可能發(fā)生這樣的情況，一方agent提供了RTCP的候選地址，但是對(duì)端可能沒(méi)有提供類似地址。有時(shí)，offer消息提供方可在同一端口多路復(fù)用RTP/RTCP數(shù)據(jù)，并且通過(guò)SDP屬性中指示了這樣的實(shí)現(xiàn)方式（多路復(fù)用RTP/RTCP參考RFC5761-5和RFC8035）。但是，如果answerer執(zhí)行了多路復(fù)用RTP/RTCP的話，offerer則不知道answerer執(zhí)行了這樣的流程，offerer就會(huì)按照默認(rèn)的設(shè)置方式使用各自獨(dú)立的RTP和RTCP，這樣處理的結(jié)果就會(huì)導(dǎo)致每個(gè)媒體流中在offer消息中包含兩個(gè)components。answerer方執(zhí)行了多路復(fù)用RTP/RTCP，對(duì)每個(gè)候選地址來(lái)說(shuō)，它將僅包含單個(gè)component。因此，此component將是RTP/RTCP mux的合并值。如果此候選地址只有單個(gè)component的話，ICE結(jié)束執(zhí)行候選地址配對(duì)。毫無(wú)疑問(wèn)，如果配對(duì)中本地候選地址和遠(yuǎn)端候選地址都是默認(rèn)候選地址時(shí)，這個(gè)候選配對(duì)被認(rèn)為是默認(rèn)的候選配對(duì)。
如果agent雙方不是ICE感知的agent的話，媒體流構(gòu)件使用此默認(rèn)候選配對(duì)傳輸媒體流。讀者可以參考以下示例來(lái)理解check list（檢查列表）核心概念和與其他模塊之間的關(guān)系。
check list列表和其他模塊之間的關(guān)系匯總
構(gòu)建候選地址配對(duì)完成以后，需要進(jìn)行后續(xù)地址配對(duì)的優(yōu)先級(jí)計(jì)算。優(yōu)先級(jí)計(jì)算是根據(jù)以下格式來(lái)計(jì)算的。其中，G表示主控方agent提供的候選優(yōu)先級(jí)，D表示被控制方提供的候選地址優(yōu)先級(jí)。這里，G>D?1:0是一個(gè)表達(dá)式，如果G大于D，則取值為1，否則為0。
pair priority = 2 ^ 32 *MIN（G,D） + 2 *MAX（G,D） + （G > D?1:0）
關(guān)于以上優(yōu)先級(jí)的計(jì)算，很多開(kāi)源項(xiàng)目有類似的處理方式，讀者可以參考一些開(kāi)源項(xiàng)目來(lái)做進(jìn)一步了解。以下一段代碼是一個(gè)配對(duì)計(jì)算源代碼示例，讀者可以參考：
// 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)先級(jí)被設(shè)定以后，agent就會(huì)按照順序?qū)蜻x地址配對(duì)進(jìn)行排序。排序的規(guī)則按照優(yōu)先級(jí)順序遞減的方式進(jìn)行。如果兩組候選地址配對(duì)有相同的優(yōu)先級(jí)，它們兩組配對(duì)的實(shí)現(xiàn)可以任意排序。
獲得了候選地址配對(duì)排序以后，此優(yōu)選候選地址會(huì)生成一個(gè)排序后的配對(duì)列表。ICE將會(huì)按照排序列表逐一進(jìn)行連接檢查。在每個(gè)檢查流程將會(huì)涉及發(fā)送請(qǐng)求的流程，agent需要從本地候選地址發(fā)送檢查請(qǐng)求到遠(yuǎn)端候選地址。這里注意，因?yàn)閍gent不能直接從反射地址發(fā)送請(qǐng)求，它僅能從base基準(zhǔn)地址發(fā)送請(qǐng)求，所以agent需要通過(guò)排序后的配對(duì)列表來(lái)發(fā)送請(qǐng)求。對(duì)每個(gè)配對(duì)來(lái)說(shuō)，如果本地候選地址是一個(gè)反射地址的話，base基準(zhǔn)地址必須替換這個(gè)反射候選地址。一旦替換流程完成后，agent必須過(guò)濾或篩選此列表。過(guò)濾配對(duì)列表的流程通過(guò)移除配對(duì)的方式來(lái)實(shí)現(xiàn)。具體來(lái)說(shuō)，如果它（需要移除的配對(duì)）的本地候選地址/遠(yuǎn)端候選地址和優(yōu)先級(jí)列表中較高優(yōu)先級(jí)的一對(duì)配對(duì)相同的話，則需要移除配對(duì)相同的較低優(yōu)先級(jí)的配對(duì)。
另外，為了安全的考慮，防止STUN服務(wù)器被攻擊，agent必須限制連接檢查數(shù)量，在一定的數(shù)值設(shè)置環(huán)境中，agent的檢查將會(huì)覆蓋所有連接列表的地址，這個(gè)特定數(shù)值必須是可配置的數(shù)值。規(guī)范RFC5245推薦默認(rèn)數(shù)值是100。候選配對(duì)列表一直保持低于100的限定設(shè)置，一些低優(yōu)先級(jí)的候選配對(duì)將被強(qiáng)制丟棄。在可能的情況下，RFC5245推薦盡量使用比較低的設(shè)置限定，在實(shí)際生產(chǎn)環(huán)境中也可能看到一些用戶針對(duì)配對(duì)檢查設(shè)置了最大檢查限定。要求支持可配置的限定設(shè)置也是為系統(tǒng)提供了一個(gè)工具，如果發(fā)現(xiàn)問(wèn)題以后，可以通過(guò)此限定值來(lái)排查問(wèn)題。
完成了候選配對(duì)地址的挑選以后，檢查列表需要進(jìn)行狀態(tài)計(jì)算。每個(gè)候選配對(duì)支持了一個(gè)foundation和一個(gè)state（狀態(tài)）。實(shí)際上，這里的foundation是合并了本地候選地址的foundation和遠(yuǎn)端的候選地址的fundation而生成的一個(gè)新的fundation。一旦開(kāi)始計(jì)算foundation時(shí)，每個(gè)配對(duì)將會(huì)設(shè)定一個(gè)狀態(tài)值，根據(jù)檢查結(jié)果的不同，候選配對(duì)需要經(jīng)過(guò)五個(gè)可能或潛在的狀態(tài)計(jì)算（歷史文章也有介紹這五個(gè)計(jì)算步驟）。
候選配對(duì)狀態(tài)計(jì)算
ICE開(kāi)始運(yùn)行時(shí)，一個(gè)候選配對(duì)將遷移到以下任何一種狀態(tài)。筆者再次重復(fù)一次每個(gè)狀態(tài)的任務(wù)然后介紹具體流程處理：
- Frozen：處于鎖定狀態(tài)，等待檢查
- Waiting：檢查還沒(méi)有啟動(dòng)，等待從check list中選擇最高優(yōu)先級(jí)的候選配對(duì)進(jìn)行處理
- In-Progress：為這個(gè)配對(duì)發(fā)送check請(qǐng)求，事務(wù)在處理流程中
- Succeeded：配對(duì)檢查成功，生成成功結(jié)果
- Failed：配對(duì)檢查失敗，既沒(méi)有生成任何響應(yīng)也沒(méi)有生成任何還原響應(yīng)
在檢查列表中的每個(gè)候選配對(duì)的初始狀態(tài)需要經(jīng)過(guò)一個(gè)狀態(tài)計(jì)算。其狀態(tài)計(jì)算需要按序經(jīng)過(guò)以下幾個(gè)步驟：
- agent將會(huì)把每個(gè)檢查列表中所有的候選配對(duì)設(shè)置為Frozen 封凍狀態(tài)。
- agent將會(huì)為第一個(gè)媒體流查詢檢查列表（第一個(gè)媒體流出現(xiàn)在SDP offer和answer中的第一個(gè)m行中）。然后針對(duì)此媒體流做狀態(tài)設(shè)定處理。對(duì)所有具有同樣foundation的配對(duì)，agent將會(huì)設(shè)置一個(gè)比較低級(jí)別component ID的配對(duì)狀態(tài)，設(shè)定這些配對(duì)進(jìn)入等待狀態(tài)。如果有多個(gè)類似這樣的配對(duì)，agent則首先使用具有最高優(yōu)先級(jí)的配對(duì)。
這里有兩個(gè)特定的列表稱謂需要讀者注意。其中檢查列表中的一部分配對(duì)會(huì)進(jìn)入等待狀態(tài)，另外一部分則進(jìn)入到封凍狀態(tài)。如果檢查列表中至少有一對(duì)配對(duì)是在等待狀態(tài)的，這樣的列表稱之為活動(dòng)檢查列表。如果檢查列表中所有配對(duì)都是封凍狀態(tài)的，這樣的列表稱之為封凍檢查列表。
除了檢查列表中的配對(duì)檢查有狀態(tài)存在，檢查列表自己本身也關(guān)聯(lián)一個(gè)狀態(tài)，針對(duì)正在工作的媒體流，這個(gè)狀態(tài)用來(lái)捕捉ICE檢查的狀態(tài)。檢查列表具有三種狀態(tài)：
- 運(yùn)行狀態(tài)：針對(duì)正在運(yùn)行的媒體流，ICE檢查狀態(tài)也在運(yùn)行中。
- 完成狀態(tài)：在這個(gè)狀態(tài)下，ICE檢查已經(jīng)生成了一個(gè)經(jīng)過(guò)挑選的配對(duì)支持媒體流構(gòu)件模塊。接下來(lái)，ICE成功完成處理任務(wù)，開(kāi)始發(fā)送媒體流。
- 失敗狀態(tài)：在這個(gè)狀態(tài)下，針對(duì)此媒體流的支持，ICE檢查還沒(méi)有成功。
作為一個(gè)offer/answer交互的結(jié)果，檢查列表首先構(gòu)建的就會(huì)被ICE遷移到運(yùn)行狀態(tài)中。ICE處理流程覆蓋所有的媒體流過(guò)程中，因此，ICE也和這個(gè)流程本身有一個(gè)關(guān)聯(lián)綁定的狀態(tài)。當(dāng)ICE運(yùn)行時(shí)，這個(gè)狀態(tài)等于運(yùn)行狀態(tài)。當(dāng)ICE處理流程完成后，這個(gè)狀態(tài)將是完成狀態(tài)，如果ICE處理流程失敗的話，這個(gè)狀態(tài)就是失敗狀態(tài)。關(guān)于以上幾個(gè)狀態(tài)之間切換的規(guī)則筆者將在定時(shí)檢查的討論中做更多說(shuō)明。
8、定時(shí)檢查
前面我們一直在討論關(guān)于check的流程，check是由全部署場(chǎng)景生成的，所以，如果agent是輕量級(jí)的部署方式的話，可以跳過(guò)此內(nèi)容討論。Agent執(zhí)行兩種check，一種是ordinary checks，另外一種是triggered checks。兩種check都是由一個(gè)定時(shí)器來(lái)控制，針對(duì)媒體流數(shù)據(jù)，定時(shí)器會(huì)周期性地觸發(fā)check生成事件。
除了定時(shí)器以外，agent也會(huì)維護(hù)一個(gè)先進(jìn)先出的隊(duì)列，這個(gè)隊(duì)列稱之為triggered check隊(duì)列，隊(duì)列維護(hù)候選配對(duì)，如果有check的機(jī)會(huì)的話，這個(gè)隊(duì)列將會(huì)發(fā)送配對(duì)進(jìn)行檢查。當(dāng)定時(shí)器觸發(fā)以后，agent將會(huì)從triggered checks隊(duì)列頂部移除一個(gè)配對(duì)，對(duì)這個(gè)配對(duì)執(zhí)行連接檢查，最后把這對(duì)候選配對(duì)的狀態(tài)設(shè)置為正在處理的狀態(tài)（In-Progress）。如果在triggered checks隊(duì)列中沒(méi)有配對(duì)的話，agent將會(huì)發(fā)送ordinary checks。
一旦完成構(gòu)建檢測(cè)列表計(jì)算的流程，agent將會(huì)針對(duì)每個(gè)active check list設(shè)置一個(gè)定時(shí)器。每Ta*N秒觸發(fā)一次定時(shí)器，這里的N是active check list的數(shù)量（初始階段，至少有一個(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í)，也應(yīng)該考慮定時(shí)器傳播的問(wèn)題，盡量不要同時(shí)對(duì)每個(gè)媒體發(fā)布定時(shí)器。第一個(gè)定時(shí)器馬上觸發(fā)后，agent在這一瞬間（offer/answer交互模式已完成）執(zhí)行連接檢查，然后在Ta秒后執(zhí)行下一個(gè)檢查（因?yàn)樵诘谝粋�(gè)定時(shí)器觸發(fā)時(shí)只有一個(gè)active check list）。
如果定時(shí)器觸發(fā)以后，agent沒(méi)有triggered checks需要發(fā)送的話，它必須按照以下規(guī)則選擇一個(gè)ordinary checks：
- 找到在等待狀態(tài)的check list中最高優(yōu)先級(jí)的配對(duì)（注意以下兩種狀態(tài)下配對(duì)處理流程）。
- 如果有這樣的配對(duì)的話：首先，從本地候選配對(duì)發(fā)送一個(gè)STUN check請(qǐng)求到遠(yuǎn)端候選配對(duì)。此STUN check請(qǐng)求將會(huì)進(jìn)行相關(guān)處理。關(guān)于STUN check請(qǐng)求的處理流程，筆者在后續(xù)文章中介紹。然后對(duì)候選配對(duì)的狀態(tài)進(jìn)行設(shè)置，設(shè)置其狀態(tài)為In-Progress狀態(tài)。
- 如果沒(méi)有這樣的配對(duì)的話：agent需要找到在封凍狀態(tài)的check list中最高優(yōu)先級(jí)的配對(duì)。如果有這樣的配對(duì)的話，對(duì)此配對(duì)解除封凍狀態(tài)，然后對(duì)此配對(duì)執(zhí)行check流程，使其狀態(tài)切換為In-Progress狀態(tài)。如果沒(méi)有這樣的配對(duì)的話，結(jié)束針對(duì)此check list的定時(shí)器。
- 配對(duì)流程完成以后，需要保證其檢查數(shù)據(jù)的完整性。如果要計(jì)算check消息的完整性，agent需要使用遠(yuǎn)端用戶名稱和密碼來(lái)完成計(jì)算。遠(yuǎn)端用戶名稱和密碼是agent學(xué)習(xí)遠(yuǎn)端peer發(fā)送的SDP中的用戶名稱和密碼獲得。
在接下來(lái)的章節(jié)中，筆者將繼續(xù)分享初始應(yīng)答接收的話題（驗(yàn)證ICE支持，決定角色等話題）。
參考資料：
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)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx FreeSBC技術(shù)文檔： www.freepbx.org.cn
融合通信/IPPBX商業(yè)解決方案：www.hiastar.com
如何使用FreeSBC，qq技術(shù)分享群：334023047
