客戶端發(fā)送綁定請求后，對端agent必須準(zhǔn)備好接收綁定請求，這個(gè)綁定請求是發(fā)送到了每個(gè)候選地址的基準(zhǔn)地址。綁定請求包含在自己最近的offer或者answer消息中。因此，即使agent是一個(gè)輕量級部署場景的agent，它也要求部署方案維持一個(gè)狀態(tài)來處理服務(wù)器端的流程。

　　接收綁定請求時(shí)，agent必須使用短期安全機(jī)制對請求進(jìn)行認(rèn)證和消息完整性檢查。Agent必須考慮用戶名稱的有效性，如果用戶名稱含有兩個(gè)用戶名稱構(gòu)成的（通過冒號：分割），其中第一個(gè)用戶名稱等于一個(gè)用戶名稱，這個(gè)用戶在此會(huì)話中，由agent在offer或者answer生成的名稱。關(guān)于名稱構(gòu)成的討論，讀者可以查閱上一篇文章。有時(shí)也存在其他的可能性，例如，提供方offerer在收到對端peer的answer之前一個(gè)收到一個(gè)綁定請求。如果這樣的情況發(fā)生，agent必須馬上生成一個(gè)響應(yīng)消息，響應(yīng)消息中包含映射地址的計(jì)算數(shù)據(jù)。在這一時(shí)間點(diǎn)，agent已經(jīng)具備了足夠的信息生成響應(yīng)消息。因此，agent就不需要對端peer的密碼。一旦agent收到answer以后，這個(gè)answer消息就會(huì)馬上通過幾個(gè)步驟進(jìn)行處理，包括檢查修復(fù)角色沖突的流程，計(jì)算映射地址的流程，通過學(xué)習(xí)獲得peer反射候選地址，Triggered Checks和更新推薦標(biāo)識(shí)。提醒讀者，以上這些流程都是針對全部署場景agent來說的。還有一些場景中，在收到answer之前，收到了多個(gè)STTUN請求，這樣就會(huì)導(dǎo)致在triggered check 隊(duì)列中生成多個(gè)配對隊(duì)列。

　　Agent一定不能使用ALTERNATE-SERVER機(jī)制，也一定不能支持RFC3489規(guī)范的向后兼容機(jī)制，它必須使用FINGERPRINT機(jī)制。

　　如果agent在媒體數(shù)據(jù)中（例如在QoS中）使用了區(qū)分服務(wù)-Diffserv（遵從RFC2475），agent也應(yīng)該使用同樣的標(biāo)識(shí)方式在綁定請求的響應(yīng)中。因?yàn)閰^(qū)分服務(wù)不在我們討論的范圍，具體關(guān)于Diffserv，讀者查閱RFC2475，這里不做進(jìn)一步討論。以下幾個(gè)步驟的討論將僅涉及全部署場景的agent處理流程。

　　正常情況下，通過agent的主控/被控方選擇，雙方可以選擇自己的成功的角色。但是，在一些非正常的環(huán)境中，例如使用了第三方的呼叫控制，雙方都成為同樣的角色。下面，筆者將討論如何檢查同一角色沖突問題，以及如何修復(fù)同一角色沖突問題。

　　Agent必須檢查綁定請求，其屬性可能是ICE- CONTROLLING或ICE-CONTROLLED 屬性。如果要檢查以上兩種屬性，agent需要按照以下流程進(jìn)行：

　　修改了agent角色以后，需要對角色的狀態(tài)進(jìn)行修復(fù)。因?yàn)楦髯越巧�的�?yōu)先級是主控方和被控方的主要執(zhí)行功能，因此agent修改屬性不是簡單切換角色就完成了工作流程。修改角色需要agent重新計(jì)算配對優(yōu)先級。這個(gè)計(jì)算方式我們在前面的歷史文章中有非常詳細(xì)地介紹，讀者可查閱此文章。agent角色切換或者修改同樣也會(huì)直接影響agent其他后續(xù)的功能執(zhí)行，例如，它是否負(fù)責(zé)選擇推薦配對，是否基于ICE結(jié)果生成更新offer的消息。

　　假設(shè)STUN服務(wù)器端對綁定請求生成了成功的響應(yīng)的話，甚至于agent角色也發(fā)生了變化，agent可以繼續(xù)執(zhí)行其余服務(wù)器端的步驟：計(jì)算映射地址，通過學(xué)習(xí)獲得peer反射候選地址等流程。

　　對于在轉(zhuǎn)發(fā)候選地址收到的請求來說，被STUN流程（即XOR-MAPPED-ADDRESS屬性生成）使用的源傳輸?shù)刂肥且粋�(gè)傳輸?shù)刂�，這個(gè)傳輸?shù)刂肥潜籗TUN認(rèn)為的傳輸?shù)刂贰Ｗx者在計(jì)算映射地址是一定要注意，這里涉及了兩種綁定請求的傳輸方式（Data Indication和ChannelData）。如果綁定請求通過Data Indication傳輸?shù)脑挘�這個(gè)源傳輸?shù)刂窌?huì)出現(xiàn)在Data Indication消息的XOR-MAPPED-ADDRESS屬性中。如果綁定請求通過ChannelData傳輸?shù)脑挘�這個(gè)源傳輸?shù)刂肥墙壎ù薱hannel 通道的地址。關(guān)于Data Indication消息和ChannelData的定義細(xì)節(jié)，讀者查閱以下兩個(gè)規(guī)范草案：

　　如果請求中的源傳輸?shù)刂凡荒芷ヅ淙魏维F(xiàn)存遠(yuǎn)端候選地址的話，這說明對端的是一個(gè)新的peer反射候選地址。這個(gè)候選地址需要通過以下方式進(jìn)行構(gòu)建：

　　下一步，agent將會(huì)構(gòu)建配對，在此配對中，本地候選地址等同于STUN請求接收的傳輸?shù)刂�，遠(yuǎn)端候選地址等同于源傳輸?shù)刂罚ㄟ@是請求發(fā)出的地址），這個(gè)地址可能是通過學(xué)習(xí)獲得的一個(gè)peer reflexive 遠(yuǎn)端候選地址。本地候選地址將是主機(jī)候選地址（這種情況下，請求可能不是通過轉(zhuǎn)發(fā)候選地址獲得），或者本地候選地址是一個(gè)轉(zhuǎn)發(fā)候選地址（這種情況下，請求通過轉(zhuǎn)發(fā)地址獲得）。此本地候選地址從來不會(huì)是服務(wù)器端反射地址。因?yàn)檫@兩個(gè)候選地址對agent來說都是可知的，所以，agent可以獲得它們的配對，然后計(jì)算其候選配對優(yōu)先級。接下來，這個(gè)配對會(huì)查詢檢查列表。通過查詢檢查列表可能獲得其中一個(gè)結(jié)果：

　　如果配對不在檢查列表時(shí)，需要進(jìn)行執(zhí)行以下流程：

　　加入到triggered check隊(duì)列以后，triggered check隊(duì)列將會(huì)被發(fā)送出去。當(dāng)triggered check隊(duì)列發(fā)送以后，其構(gòu)建和處理的流程按照前面討論的發(fā)送請求來處理。具體關(guān)于發(fā)送請求的詳情，讀者可參與筆者上一篇文章，或者查閱RFC5245-7.1.2，這里不再重復(fù)。這些流程要求agent獲得一個(gè)傳輸?shù)刂�，部分用戶名（username fragment），對端peer密碼。這里讀者還要再次注意用戶名稱和密碼的設(shè)置。遠(yuǎn)端候選地址的用戶名稱（username fragment）等于收到的綁定請求中，冒號后面的USERNAME名稱，agent使用此用戶名稱檢查從peer收到的SIP消息（可能從多個(gè)分叉中檢查），然后找到此用戶名稱（username fragment），然后通過此用戶名稱選擇相應(yīng)的密碼。關(guān)于用戶名稱和密碼構(gòu)成的處理方式，讀者可以參考上一篇文章中的介紹。

　　本文章中以上討論的都是基于全場景部署的agent的討論。輕量級的部署場景agent的處理相對比較簡單，使用的場景也不是非常普遍，因此沒有太多的約定條件（沒有優(yōu)先級，foundation等計(jì)算設(shè)置，沒有隊(duì)列檢查等流程）。這里，筆者針對輕量級部署場景的agent做一些簡單說明，希望讀者引起注意。如果收到的check消息中包含了USE-CANDIDATE設(shè)置屬性，agent將需要構(gòu)建一個(gè)候選配對。其中候選配對中，本地候選地址等于傳輸?shù)刂罚ㄊ盏秸埱蟮牡刂罚�，遠(yuǎn)端候選地址等于一個(gè)源傳輸?shù)刂罚ㄗ⒁�，這個(gè)地址是收到請求的源傳輸?shù)刂罚�。�?gòu)建成的候選配對設(shè)定一個(gè)任意優(yōu)先級，然后推送到有效候選列表中（valid list）。Agent然后設(shè)置這對候選配對的推薦標(biāo)識(shí)為true。針對媒體流的每個(gè)構(gòu)件模塊，如果這個(gè)有效候選列表包含了一對候選配對，媒體流的ICE處理流程將被視作完成狀態(tài)。

　　到此為止，結(jié)合上一篇文章中關(guān)于STUN客戶端處理流程介紹，筆者已經(jīng)完成了關(guān)于ICE連接檢查的討論（客戶端處理流程和本章節(jié)的服務(wù)器端處理流程）。在接下來的章節(jié)中，筆者將重點(diǎn)討論關(guān)于ICE結(jié)束處理的流程。

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

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