孙俪最新视频,佟丽娅性感视频,韩国美女酒店激情在线视频

　　在上一篇文章中，筆者討論了STUN 連接檢查的客戶端的處理流程。接下來，在本章節(jié)，筆者繼續(xù)討論關于服務器端的處理流程。

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

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

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

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

　　1、檢測修復角色沖突

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

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

如果在請求中，其屬性既不是ICE-CONTROLLING，也不是ICE-CONTROLLED屬性的話，說明agent沒有遵從RFC5245規(guī)范，這里有角色沖突的問題，但是agent目前執(zhí)行不了檢測。
如果agent是一個被控方角色，并且請求中出現(xiàn)了ICE-CONTROLLING屬性，接下來根據(jù)具體屬性內容大小進行判斷：
如果agent的tie-breaker大于或等于ICE-CONTROLLING的內容，此agent生成一個綁定錯誤響應，錯誤響應中包含一個ERROR-CODE屬性（487-角色沖突），這里，agent角色仍然保持不變。
如果agent的tie-breaker小于ICE-CONTROLLING的內容，agent切換到主控方agent角色。
如果agent是一個主控方agent角色，并且請求中出現(xiàn)了ICE-CONTROLLED屬性，接下來根據(jù)具體屬性內容進行判斷：
如果agent的tie-breaker大于或等于ICE-CONTROLLED的內容，agent切換到被控方角色。
如果agent的tie-breaker小于ICE-CONTROLLED的內容，此agent生成一個綁定錯誤響應，錯誤響應中包含一個ERROR-CODE屬性（487-角色沖突），這里，agent角色仍然保持不變。
如果agent是主控方角色agent，并且ICE-CONTROLLING屬性出現(xiàn)在了請求中，或者agent是被控方角色agent，并且ICE-CONTROLLED屬性出現(xiàn)在了請求中，雙方角色無沖突。

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

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

　　2、計算映射地址

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

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

　　3、學習Peer Reflexive Candidates

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

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

　　4、Triggered Checks處理

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

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

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

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

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

　　5、更新推薦Flag標識

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

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

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

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

　　參考資料：

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

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