亚洲另类天天更新影院在线观看_完整SIP/SDP媒體協(xié)商概論-關(guān)于ICE流程結束處理 - 國內

　　筆者在前面的兩篇文章中分別介紹了STUN客戶(hù)端處理流程和服務(wù)器端處理流程。在本文章中，我們將針對ICE的最后一部分的處理進(jìn)行總結，這個(gè)章節包括ICE的流程結束的處理。ICE流程結束需要從兩種部署場(chǎng)景的agent來(lái)討論。一種是全場(chǎng)景部署agent的處理流程，另外一種是輕量級的部署場(chǎng)景agent處理流程。另外，ICE結束流程的最后還要進(jìn)行對封凍候選地址的處理。和前面的文章一樣，筆者這里仍然還是重點(diǎn)討論全場(chǎng)景部署agent的處理流程，然后針對輕量級場(chǎng)景中agent的部署進(jìn)行討論，最后對ICE結束對封凍候選地址進(jìn)行討論。

　　1、全部署場(chǎng)景處理流程

　　針對全場(chǎng)景部署agent的處理流程中，關(guān)于ICE結束的流程涉及了推薦配對和狀態(tài)機更新兩個(gè)部分的內容。其中，推薦配對是由被控方agent產(chǎn)生。接下來(lái)，筆者會(huì )繼續討論推薦配對的處理流程。

　　2、推薦配對

　　剛才筆者已經(jīng)提到，推薦配對是由被控方產(chǎn)生的。ICE通過(guò)Regular Nomination（正常推薦方式）或Aggressive Nomination（主動(dòng)推薦方式）來(lái)選擇推薦配對。選擇何種方式對推薦配對進(jìn)行算法處理，取決于對端pper的部署場(chǎng)景。如果對端peer支持的是一個(gè)輕量級部署場(chǎng)景，agent必須使用Regular Nomination算法來(lái)處理。如果對端peer使用了ice-options屬性（ICE options），agent不能理解此選項的話(huà)，agent必須使用Regular Nomination算法。如果對端peer支持全場(chǎng)景部署，并且沒(méi)有使用任何ICE選項或者使用了ICE選項（但是，agent可以理解），agent可以選擇使用Regular Nomination或者Aggressive Nomination算法。但是，因為Regular Nomination的穩定性比Aggressive Nomination要好，所以，RFC5245規范推薦使用Regular Nomination算法。下面，筆者分別對這兩種算法進(jìn)行完整介紹。

　　圖片來(lái)自于互聯(lián)網(wǎng)

　　當推薦配對使用Regular Nomination時(shí)，agent會(huì )讓一些檢查流程完成處理，在檢查的每個(gè)流程中會(huì )忽略掉USE-CANDIDATE屬性。針對一個(gè)媒體流構件來(lái)說(shuō)，一旦一個(gè)或多個(gè)檢查成功完成，成功檢查完成后會(huì )生成有效配對，有效配對然后添加到有效列表中。Agent會(huì )讓檢查繼續執行，直到檢查遇到某些評判標準，然后根據某些評判標準選擇有效配對。停止檢查的評判標準和評估有效配對標準完全取決于邏輯優(yōu)化本身自己。

　　當被控方agent選擇了一對有效配對時(shí)，它會(huì )重復這個(gè)生成有效配對的檢查，并且這次使用USE-CANDIDATE屬性。因為前面的檢查是成功的，所以，理論上講，這個(gè)檢查應該也是一個(gè)成功的檢查。針對檢查的邏輯處理方式會(huì )對配對增加一個(gè)推薦標識（nominated flag），并且僅支持這個(gè)配對。因此，針對每個(gè)媒體構件來(lái)說(shuō)，在有效列表中僅有一個(gè)單個(gè)支持了推薦標識配對，并且，當檢查列表的狀態(tài)切換到完成狀態(tài)后，ICE會(huì )選擇正確配對來(lái)針對媒體構件發(fā)送和接收媒體流。根據以上介紹，讀者可以看出，因為agent可以控制檢查停止和檢查的評判標準，因此，Regular Nomination具有更大的靈活性。這里只有一個(gè)要求，agent最后選擇一個(gè)配對或者只能選擇一個(gè)候選配對，然后針對此配對（支持USE-CANDIDATE屬性）生成一個(gè)檢查。通過(guò)增加拓展支持，Regular Nomination同時(shí)提高了ICE的適應能力，可以支持多種部署場(chǎng)景的變化。Regular Nomination具有更高的穩定性，它可以允許雙方agent通過(guò)單個(gè)配對實(shí)現媒體支持，無(wú)需其他臨時(shí)選項支持（Aggressive Nomination需要臨時(shí)選項支持）。但是，Regular Nomination也有其缺點(diǎn)，因為Regular Nomination需要額外檢查完成，因此，Regular Nomination肯定會(huì )增加處理時(shí)延。通過(guò)以上內容的介紹，筆者描述了Regular Nomination算法的處理方式，接下來(lái)，筆者介紹一下Aggressive Nomination算法的使用方式。

　　當使用Aggressive Nomination算法時(shí)，在agent發(fā)生的每個(gè)檢查中，被控方agent會(huì )包含一個(gè)USE-CANDIDATE屬性，針對一個(gè)媒體構件的檢查中，一旦第一個(gè)檢查是成功的，這個(gè)配對就會(huì )被添加到有效列表中，然后設置一個(gè)推薦標識。在有效列表中，所有構件的配對都設置了推薦標識后，媒體開(kāi)始通過(guò)最高優(yōu)先級的推薦標識配對進(jìn)行傳輸。但是，因為agent在所有的檢查中都包含了USE-CANDIDATE屬性，在所有的檢查中，有可能部分其他的檢查還沒(méi)有完成，這樣就會(huì )引起其他有效配對會(huì )產(chǎn)生自己的推薦標識設置。因為，ICE總是從有效列表中選擇最高優(yōu)先級推薦標識的候選配對來(lái)進(jìn)行媒體傳輸。因此，當ICE檢查完成時(shí)，已選擇的配對可能實(shí)際上暫時(shí)發(fā)生了修改，這樣就會(huì )導致一系列的臨時(shí)選擇作為一個(gè)緩沖（三秒延遲規則，后面講到），直到ICE檢查穩定后，這樣的狀態(tài)才能結束。因為這個(gè)問(wèn)題，因此，相對于Regular Nomination算法來(lái)說(shuō)，Aggressive Nomination缺乏一定的穩定性。但是它不會(huì )增加檢查延時(shí)。

　　3、更新ICE處理狀態(tài)

　　無(wú)論是對于主控方agent還是被控方agent來(lái)說(shuō)，ICE的處理狀態(tài)取決于在有效列表中標識候選配對的當前狀態(tài)和檢查列表的狀態(tài)。任何時(shí)間內，以下五種場(chǎng)景可能發(fā)生在這些處理狀態(tài)中。現在，我們具體介紹一下這五種可能發(fā)生的場(chǎng)景。

　　對媒體流來(lái)說(shuō)，如果在有效列表中沒(méi)有已設推薦標識的配對，并且檢查列表狀態(tài)是正在運行中，ICE處理將會(huì )繼續執行。

　　對媒體流來(lái)說(shuō)，如果在有效列表中至少有一對已設推薦標識的配對，并且檢查列表狀態(tài)是正在運行中，則繼續進(jìn)行以下處理流程：

Agent必須移除在檢查列表中所有等待狀態(tài)和封凍狀態(tài)的配對，并且為同樣component（構件）啟動(dòng)一個(gè)triggered check queue，作為標識配支持此媒體流。
如果在檢查列表中的一個(gè)In-Progress配對作為標識配對支持同樣構件的話(huà)，如果配對的優(yōu)先級低于最低優(yōu)先級標識配對，針對此構件來(lái)說(shuō)，agent應該清除檢查的重傳處理流程。
對于至少一個(gè)媒體流的每個(gè)構件來(lái)說(shuō)，在有效列表中一旦至少有一對標識配對，并且檢查列表的狀態(tài)是正在運行中的狀態(tài)，需要進(jìn)一步執行以下流程：
Agent必須為此媒體的檢查列表進(jìn)行狀態(tài)修改，修改其狀態(tài)為完成狀態(tài)。
Agent必須繼續對任何檢查做出響應，這些檢查可能仍然是agent用來(lái)接收媒體的響應，并且，如果STUN 服務(wù)器端流程要求的話(huà)，agent必須執行triggered check。
Agent必須為檢查列表繼續重傳任何In-Progress 檢查。
Agent可以開(kāi)始為媒體流傳輸媒體，為全場(chǎng)場(chǎng)景部署agent和輕量級場(chǎng)景部署agent發(fā)送媒體的處理流程將在后續文章中介紹。

　　一旦每個(gè)檢查列表的狀態(tài)是完成狀態(tài)，要求執行以下流程：

　　Agent設置所有的ICE處理狀態(tài)是完成狀態(tài)。

　　如果agent是正在處于被控狀態(tài)，此agent會(huì )為每個(gè)媒體流的每個(gè)構件檢查最高優(yōu)先級已標識的候選配對。如果它們中的任何候選配對不同于在最近offer/answer交互消息在的默認候選配對，被控方agent必須生成一個(gè)更新的offer。具體的生成方式根據后續offer/answer交互模式的處理流程進(jìn)行。

　　如果被控方agent正在使用Aggressive Nomination，當配對選擇時(shí)，它可能導致多個(gè)更新offers。Agent可以延遲發(fā)送此更新的offer，通過(guò)一定的時(shí)間設置進(jìn)行控制（RFC5245規范建議設置為一秒鐘），這個(gè)時(shí)間可以保證其已選配對進(jìn)入穩定狀態(tài)。

　　如果檢查列表的狀態(tài)是失敗狀態(tài)，ICE將不能為完成針對媒體流的處理。正確的處理方式依賴(lài)于對其他媒體流的檢查列表狀態(tài)：

如果所有的檢查列表的狀態(tài)是失敗狀態(tài)，所有ICE處理的狀態(tài)將認為是失敗狀態(tài)，并且，agent應該認為此會(huì )話(huà)是一個(gè)失敗的會(huì )話(huà)，agent不應該重新啟動(dòng)ICE處理流程，被控方agent應該結束整個(gè)會(huì )話(huà)。
針對其他媒體流來(lái)說(shuō)，如果在檢查列表中至少有一個(gè)檢查的狀態(tài)是完成狀態(tài)，被控方agent應該在其更新的offer中從此會(huì )話(huà)中移除此失敗的媒體流。
針對其他媒體流來(lái)說(shuō)，如果在檢查列表中沒(méi)有任何檢查是完成狀態(tài)，但是，至少有一個(gè)檢查是正在運行狀態(tài)，agent應該讓ICE進(jìn)行執行。
到此為止，關(guān)于ICE結束處理中全場(chǎng)景部署agent的處理流程就已經(jīng)結束。接下來(lái)，筆者將討論針對輕量級部署場(chǎng)景agent對ICE結束流程的處理。

　　4、輕量級部署場(chǎng)景處理流程

　　針對輕量級部署場(chǎng)景agent來(lái)說(shuō)，ICE結束流程相對比較直接。這里有兩個(gè)情況需要注意：

部署場(chǎng)景是輕量級的部署場(chǎng)景，對端peer是全場(chǎng)景部署場(chǎng)景
部署場(chǎng)景是輕量級部署場(chǎng)景，對端peer也是輕量級部署場(chǎng)景

　　ICE結束處理會(huì )給agent帶來(lái)一個(gè)后續影響，agent能夠清除任何已分配的候選地址（ICE沒(méi)有使用這些候選地址）。關(guān)于清除已分配候選地址的處理方式，筆者在本文章的后續部分介紹。

　　如果對端peer是全部署場(chǎng)景的話(huà)，這種情況下，agent將會(huì )收到peer的連接檢查。當agent已經(jīng)收到來(lái)一個(gè)連接檢查，這個(gè)檢查中包含了針對一個(gè)媒體流的每個(gè)構件所支持的USE-CANDIDATE屬性，此媒體流的ICE處理狀態(tài)將要從正在運行狀態(tài)遷移到完成狀態(tài)。當針對所有媒體流的ICE處理狀態(tài)是完成狀態(tài)的話(huà)，所有ICE處理狀態(tài)都是完成狀態(tài)。輕量級部署從來(lái)不自己決定針對媒體流的ICE流程失敗處理，而是寧愿讓全場(chǎng)景部署的agent來(lái)決定。在后續的offer中，針對失敗的媒體流，全場(chǎng)景部署將做出決定，移除或重新啟動(dòng)這些失敗的媒體流。

　　如果對端peer是輕量級peer的話(huà)，ICE結束處理的流程相對比較復雜一些。一旦offer/answer交互模式完成后，雙方agent都會(huì )檢查它們的候選地址和它的peer的候選地址。針對每個(gè)媒體流，每個(gè)agent將會(huì )使用自己候選地址和對端peer的候選地址進(jìn)行配對處理。當它們具有同樣的component，使用同樣的傳輸協(xié)議（RFC5245使用UDP傳輸協(xié)議），并且來(lái)自于同一IP地址類(lèi)型（IPv4或IPV6），那么這兩個(gè)候選地址就會(huì )配對。在生成配對后，針對每個(gè)媒體流構件中的配對數量有兩種處理方式：

　　如果在每個(gè)媒體構件中，有一個(gè)單個(gè)配對的話(huà)，此配對會(huì )添加到有效列表中。如果一個(gè)媒體的所有構件只有一個(gè)配對的話(huà)，針對此媒體流的ICE處理狀態(tài)將會(huì )設置為完成狀態(tài)。如果所有媒體流的ICE處理狀態(tài)是完成狀態(tài)的話(huà)，所有ICE處理狀態(tài)將會(huì )設置為完成狀態(tài)。這種部署環(huán)境經(jīng)常會(huì )發(fā)生在IPv4的網(wǎng)絡(luò )環(huán)境中。

　　如果在每個(gè)構件中，有多于一個(gè)以上的配對的話(huà)，需要執行以下幾個(gè)步驟：

Agent必須基于本地策略選擇一個(gè)配對。因為，這種情況僅發(fā)生在IPv6的環(huán)境中，RFC5245推薦agent需要根據RFC6724的處理流程選擇一個(gè)單個(gè)配對。
Agent會(huì )在有效列表中為每個(gè)構件添加此已選配對。然后允許開(kāi)始發(fā)送媒體。這里要注意，但是在實(shí)際環(huán)境中，可能雙方agent已選擇了不同的配對。

　　為了保持雙方agent的配對的一致性，被控方agent必須發(fā)送一個(gè)更新的offer，在這個(gè)更新的offer中包含一個(gè)remote-candidates屬性設置。關(guān)于更新offer的發(fā)送處理流程，筆者在將來(lái)的討論中介紹。

　　當offer發(fā)送以后，agent一定不能更新ICE處理狀態(tài)。針對所有媒體流，如果此后續offer完成處理，主控方agent必須修改ICE處理流程狀態(tài)為完成狀態(tài)，并且設置所有ICE處理狀態(tài)為完成狀態(tài)。主控方agent的狀態(tài)設置則基于輕量級部署場(chǎng)景的流程來(lái)進(jìn)行處理。

　　5、封凍候選地址

　　在ICE結束處理的流程中，包括兩種對后選地址的封凍處理。一種是全場(chǎng)景部署中封凍處理，另外一種是輕量級的部署場(chǎng)景封凍處理。接下來(lái)，筆者分別對其流程進(jìn)行說(shuō)明。

　　首先介紹全場(chǎng)景中關(guān)于封凍處理的流程。ICE結束處理的流程要求agent繼續監聽(tīng)STUN請求，一旦對其媒體流的處理完成后，繼續對媒體流生成triggered checks。RFC5245介紹了一種規則，規則描述了當agent處于安全狀態(tài)時(shí)，它在一個(gè)候選地址（ICE沒(méi)有選擇此候選地址，然后釋放候選地址）終止發(fā)送或接收檢查。

　　當SIP網(wǎng)絡(luò )中使用了ICE，并且offer被經(jīng)過(guò)分叉處理發(fā)送到多個(gè)接收方時(shí)，ICE將會(huì )使用同樣的本地候選地址并行和每個(gè)自己的answer進(jìn)行處理。對所有使用那些候選地址來(lái)傳輸媒體流的peers來(lái)說(shuō)，一旦ICE處理流程狀態(tài)達到完成狀態(tài)，agent應該等待另外三秒鐘，然后agent可以終止對檢查的響應，或在那個(gè)候選地址生成一個(gè)triggered checks。Agent可以在那個(gè)等待時(shí)間釋放候選地址。注意，服務(wù)器端反射候選地址的封凍處理從來(lái)不會(huì )被明確聲明，keepalive的缺失會(huì )啟動(dòng)封凍處理流程發(fā)生。三秒延遲的規則策略可以處理如下場(chǎng)景，具體來(lái)說(shuō)，ICE已經(jīng)完成后，agent使用了aggressive nomination算法，然后對已選配對進(jìn)行快速修改。

　　輕量級部署場(chǎng)景中ICE結束處理相對比較簡(jiǎn)單。對所有使用那些候選地址來(lái)傳輸媒體流的peers來(lái)說(shuō)，一旦ICE處理流程狀態(tài)達到完成狀態(tài)，輕量級部署場(chǎng)景可以釋放任何沒(méi)有被ICE選擇的候選地址。

　　完成了關(guān)于ICE的討論以后，筆者將進(jìn)一步討論關(guān)于后續offer/answer交互中的offer生成，answer接收，更新offer等細節。

　　參考資料：

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

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

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

　　https://datatracker.ietf.org/meeting/93/materials/slides-93-mmusic-3

　　https://bugzilla.mozilla.org/show_bug.cgi?id=1034964