亚洲日本在线看片_完整SIP/SDP媒體協(xié)商概論-STUN連接檢查-服務(wù)器端流程 - 國內

　　在上一篇文章中，筆者討論了STUN 連接檢查的客戶(hù)端的處理流程。接下來(lái)，在本章節，筆者繼續討論關(guān)于服務(wù)器端的處理流程。

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

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

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

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

　　1、檢測修復角色沖突

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

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

如果在請求中，其屬性既不是ICE-CONTROLLING，也不是ICE-CONTROLLED屬性的話(huà)，說(shuō)明agent沒(méi)有遵從RFC5245規范，這里有角色沖突的問(wèn)題，但是agent目前執行不了檢測。
如果agent是一個(gè)被控方角色，并且請求中出現了ICE-CONTROLLING屬性，接下來(lái)根據具體屬性?xún)热荽笮∵M(jìn)行判斷：
如果agent的tie-breaker大于或等于ICE-CONTROLLING的內容，此agent生成一個(gè)綁定錯誤響應，錯誤響應中包含一個(gè)ERROR-CODE屬性（487-角色沖突），這里，agent角色仍然保持不變。
如果agent的tie-breaker小于ICE-CONTROLLING的內容，agent切換到主控方agent角色。
如果agent是一個(gè)主控方agent角色，并且請求中出現了ICE-CONTROLLED屬性，接下來(lái)根據具體屬性?xún)热葸M(jìn)行判斷：
如果agent的tie-breaker大于或等于ICE-CONTROLLED的內容，agent切換到被控方角色。
如果agent的tie-breaker小于ICE-CONTROLLED的內容，此agent生成一個(gè)綁定錯誤響應，錯誤響應中包含一個(gè)ERROR-CODE屬性（487-角色沖突），這里，agent角色仍然保持不變。
如果agent是主控方角色agent，并且ICE-CONTROLLING屬性出現在了請求中，或者agent是被控方角色agent，并且ICE-CONTROLLED屬性出現在了請求中，雙方角色無(wú)沖突。

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

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

　　2、計算映射地址

　　對于在轉發(fā)候選地址收到的請求來(lái)說(shuō)，被STUN流程（即XOR-MAPPED-ADDRESS屬性生成）使用的源傳輸地址是一個(gè)傳輸地址，這個(gè)傳輸地址是被STUN認為的傳輸地址。讀者在計算映射地址是一定要注意，這里涉及了兩種綁定請求的傳輸方式（Data Indication和ChannelData）。如果綁定請求通過(guò)Data Indication傳輸的話(huà)，這個(gè)源傳輸地址會(huì )出現在Data Indication消息的XOR-MAPPED-ADDRESS屬性中。如果綁定請求通過(guò)ChannelData傳輸的話(huà)，這個(gè)源傳輸地址是綁定此channel 通道的地址。關(guān)于Data Indication消息和ChannelData的定義細節，讀者查閱以下兩個(gè)規范草案：

Data Indication：https://tools.ietf.org/id/draft-rosenberg-midcom-turn-08.txt
ChannelData：https://tools.ietf.org/html/rfc5766-10

　　3、學(xué)習Peer Reflexive Candidates

　　如果請求中的源傳輸地址不能匹配任何現存遠端候選地址的話(huà)，這說(shuō)明對端的是一個(gè)新的peer反射候選地址。這個(gè)候選地址需要通過(guò)以下方式進(jìn)行構建：

此候選地址的優(yōu)先級設置為請求中獲得的PRIORITY 屬性值。
候選地址類(lèi)型設置為peer reflexive。
候選地址的foundation設置為一個(gè)任意值，這個(gè)foundation必須區別于所有其他遠端候選地址的foundation。如果在SDP的后續的offer/answer交互中包含了peer reflexive候選地址，這將表示對此候選地址來(lái)說(shuō)，這是一個(gè)真實(shí)的foundation。
此候選地址的component ID設置為一個(gè)component ID，這個(gè)ID是為本地候選地址到遠端地址（發(fā)送請求的地址）。
構建候選地址完成后，這個(gè)候選地址將被添加到遠端候選地址列表中。但是，agent還不會(huì )使用本地候選地址和這個(gè)遠端候選地址進(jìn)行配對處理。在triggered check流程會(huì )進(jìn)行本地候選地址和其配對的處理。

　　4、Triggered Checks處理

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

如果配對已在檢查列表中，繼續執行以下四種檢查：
如果配對在等待或封凍狀態(tài)，如果檢查沒(méi)有出現在triggered check隊列中，把此配對的檢查流程加入到triggered check隊列中。
如果配對在In-Progress 狀態(tài)，agent將會(huì )取消這個(gè)事務(wù)處理。這里取消的意思是agent將不在重傳請求，將不會(huì )認為缺乏響應是失敗的，但是會(huì )在事務(wù)超時(shí)時(shí)間內對此響應執行等待流程。另外，通過(guò)對agent進(jìn)行隊列排序，此agent將會(huì )被加入到triggered check隊列中，因此會(huì )讓agent創(chuàng )建一個(gè)新的連接檢查，然后，agent必須對此配對創(chuàng )建一個(gè)新的連接檢查（重新作為一個(gè)新的STUN綁定請求事務(wù)）。最后，這個(gè)配對的狀態(tài)切換為等待狀態(tài)。
如果配對狀態(tài)是失敗狀態(tài)，此狀態(tài)必須切換為等待狀態(tài)，并且通過(guò)把agent加入triggered check隊列，由此觸發(fā)agent創(chuàng )建一個(gè)新的連接檢查。接下來(lái)，agent必須為這一對配對創(chuàng )建一個(gè)新的檢查連接（重新作為一個(gè)新的STUN綁定請求事務(wù)）。
如果配對狀態(tài)是成功狀態(tài)，agent則無(wú)需執行進(jìn)一步處理步驟。
當雙方agent在NAT背后時(shí)，通過(guò)以上步驟處理來(lái)支持ICE的快速處理。

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

基于配對優(yōu)先級，配對會(huì )插入到檢查列表中
配對狀態(tài)設置為等待狀態(tài)
配對會(huì )加入到triggered check隊列中

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

　　5、更新推薦Flag標識

如果必要，配對的推薦方式標識也是需要更新的。如果agent收到了一個(gè)綁定請求，綁定請求中已有一個(gè)USE-CANDIDATE設置屬性，并且這個(gè)agent是一個(gè)主控方agent，agent將會(huì )查看配對狀態(tài)（根據上一個(gè)討論中的計算方式），并且繼續進(jìn)行判斷處理：
如果這個(gè)配對狀態(tài)是成功狀態(tài)，這表示由這對配對生成的檢查流程生成了一個(gè)成功的響應。這會(huì )引起agent的一個(gè)更新處理。當成功響應收到以后，agent會(huì )構建一對有效配對。關(guān)于構建有效配對的流程，讀者可以參考筆者的客戶(hù)端流程處理的文章。構建配對后，agent會(huì )將配對的推薦標識設置為true值。這樣的設置方式可能會(huì )結束此媒體流的ICE處理流程。
如果配對狀態(tài)是In-Progress狀態(tài)的話(huà)，如果agent的檢查流程生成了成功的結果，當響應抵達時(shí)，隨之生成的有效配對已確定了的推薦標識設置。當響應抵達時(shí)，這樣的設置方式可能會(huì )結束此媒體流的ICE處理流程。關(guān)于ICE結束處理流程的討論，筆者將在下一篇文章做做詳細說(shuō)明。

　　6、針對Lite部署的額外流程處理討論

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

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

　　參考資料：

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

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