在全場(chǎng)景部署的更新處理流程中涉及了四個(gè)方面的內容需要討論。首先，我們介紹一下關(guān)于ICE重新啟動(dòng)的內容。

　　在ICE重新啟動(dòng)之前，針對媒體流的每個(gè)構件，agent必須記住在有效列表中的最高優(yōu)先級標識的配對（稱(chēng)之為歷史已選配對）。Agent將會(huì )繼續使用這些配對發(fā)送媒體流。發(fā)送媒體流的流程在后面的文章中會(huì )加以討論。一旦目的地地址收到提示信息，agent必須刷新有效列表和檢查列表中的數據。然后agent重新計算檢查列表和其狀態(tài)。具體處理流程參考歷史文章中關(guān)于構建檢查列表的流程。

　　如果在offer/answer交互中已添加了一個(gè)新的媒體流，agent必須為此新媒體流創(chuàng )建一個(gè)新的檢查列表，還創(chuàng )建一個(gè)新的初始為空的有效列表。具體處理流程參考歷史文章中關(guān)于構建檢查列表的流程。

　　如果在offer/answer交互要移除一個(gè)媒體流或answer拒絕了offer中提供的媒體流的話(huà)，agent必須為此媒體流刷新有效列表，必須結束在任何處理過(guò)程的STUN事務(wù)。agent必須為此媒體流移除檢查列表，并且取消任何待處理的ordinary checks。

　　針對全場(chǎng)景部署中的更新有效列表和檢查列表，ICE的處理根據agent的狀態(tài)和檢查列表狀態(tài)的不同存在很多不同流程。首先說(shuō)明，除非正在ICE重新啟動(dòng)，否則有效列表是不會(huì )受更新offer/answer交互影響。

　　針對一個(gè)媒體流來(lái)說(shuō)，如果agent的狀態(tài)是正在運行狀態(tài)，檢查列表是已更新?tīng)顟B(tài)（如果狀態(tài)是完成狀態(tài)，檢查列表已無(wú)相關(guān)性）。為了實(shí)現這個(gè)要求，agent必須使用計算流程重新計算檢查列表。具體處理流程參考歷史文章中關(guān)于構建檢查列表的流程。在計算結果中，如果發(fā)現在檢查列表中有一對配對已經(jīng)是全面檢查列表中出現的配對的話(huà)，其配對狀態(tài)是Waiting，In-Progress，Succeeded或Failed狀態(tài)的話(huà)，其狀態(tài)將被拷貝到檢查列表中；否則其狀態(tài)將設置為封凍狀態(tài)（Frozen）。

　　如果檢查列表中無(wú)任何活動(dòng)配對（意味著(zhù)每個(gè)檢查列表中的配對是封凍狀態(tài)），full-mode（雙方agent都使用了ICE）的 agent為第一個(gè)媒體流在有效列表中設置第一個(gè)配對，設置的第一個(gè)配對的狀態(tài)為等待狀態(tài)，然后把在檢查列表中具有同樣component ID和具有同樣foundation所有其他配對設置為等待狀態(tài)。

　　接下來(lái)，agent會(huì )逐一執行某個(gè)檢查列表，最高優(yōu)先級的配對首先開(kāi)始執行。如果列表中有一個(gè)配對狀態(tài)是成功狀態(tài)，其component ID設置為1，然后繼續執行以下處理。在同樣檢查列表中，如果所有其他封凍狀態(tài)的配對具有同樣foundation，并且在這些具有同樣foundation配對中，如果它們的component ID不是1的話(huà)，agent將把這些封凍的配對的狀態(tài)設置為等待狀態(tài)。針對一個(gè)具體的檢查列表，如果媒體流的每個(gè)構件的配對有一對在成功狀態(tài)，為其他所有媒體流的第一個(gè)構件（可能在不同的檢查列表中），agent將會(huì )把所有具有同樣foundation，其配對狀態(tài)處于封凍狀態(tài)的配對的狀態(tài)進(jìn)行狀態(tài)遷移，這些配對的狀態(tài)從封凍狀態(tài)設置為等待狀態(tài)。

　　輕量級的部署場(chǎng)景中關(guān)于更新列表檢查的處理比較簡(jiǎn)單。如果為一個(gè)媒體流重新啟動(dòng)ICE，agent也必須為此媒體流重新啟動(dòng)一個(gè)有效列表。Agent也必須記得此媒體流的每個(gè)構件的上次有效列表中的配對（稱(chēng)之為歷史已選配對）。然后根據流程繼續發(fā)送媒體流。流程的規則定義在將來(lái)的文章中介紹。接下來(lái)，針對每個(gè)媒體流的ICE處理狀態(tài)必須修改為正在運行狀態(tài)。

　　在實(shí)際應用場(chǎng)景中，我們經(jīng)常遇到一些用戶(hù)的反饋WebRTC的兼容性問(wèn)題，自己也經(jīng)常面臨WebRTC的兼容性問(wèn)題。我們不得不經(jīng)常更新一些功能支持，同時(shí)也不得不不斷學(xué)習新的知識。其實(shí)，我們從RFC5245以及其最新規范8445中就可以看出，這些處理流程在最近幾年內進(jìn)行了很多次修改。現在，我們介紹一個(gè)特殊的ICE選項。除了在RFC5245中規定的ICE啟動(dòng)流程以外，在最新的RFC8445中增加了一個(gè)ICE選項-ice2 選項。當ICE agent在候選交互中包含了ice2選項以后，表示需要遵從RFC8445規范。在一些特定的交互中使用ice2讓對端peer獲悉agent也不再使用此交互流程。例如，在RFC8445中已經(jīng)移除了主動(dòng)推薦標識的流程（aggressive nomination procedure），如果agent需要通知對端不再使用此交互流程時(shí)，可以增加一個(gè)ice2選項來(lái)表示。

　　一個(gè)agent如果遵從RFC8445的話(huà)，在候選地址交互開(kāi)始時(shí)必須通過(guò)ice2通知對端peer其交互模式啟用了ice2選項。否則，對端可能收到一個(gè)未知的ice選項。

　　關(guān)于對ice2的編碼和對對端peer的消息傳輸，讀者可以參與RFC4566中的參考規范。在其參考規范中詳細說(shuō)明了ICE-SIP-SDP的細節。最新的草案參考鏈接如下：

　　https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39

　　另外，再次提醒讀者，如果要開(kāi)發(fā)最新的SIP和WebRTC的業(yè)務(wù)應用的話(huà)，因為ICE處理流程中SDP的頻繁更迭，讀者一定要關(guān)注最新的RFC8445規范以及關(guān)于SDP構建的草案。

　　無(wú)論是否使用ICE或者媒體流的狀態(tài)如何，keepalives是終端保持存活的重要手段。大家知道，為了終端保持狀態(tài)的活動(dòng)狀態(tài)，所有的終端都必須不斷向服務(wù)器端發(fā)送存活消息。針對媒體會(huì )話(huà)來(lái)說(shuō)，存活消息的目的就是為了保持NAT綁定存活狀態(tài)。無(wú)論媒體流狀態(tài)是inactive，sendonly，recvonly還是sendrecv狀態(tài)，并且也不管在線(xiàn)狀態(tài)，帶寬屬性設置狀態(tài)，終端必須發(fā)送keepalives。即使周期會(huì )話(huà)中完全沒(méi)有使用ICE，終端也必須發(fā)送keepalives。終端應該使用對端peer能夠支持的格式來(lái)發(fā)送keepalives。ICE終端允許基于STUN的keepalives支持UDP的流。具體來(lái)說(shuō)，當agent是一個(gè)全場(chǎng)景部署的agent，并且和對端peer（輕量級部署場(chǎng)景或全場(chǎng)景部署agent）通信時(shí)，它們之間必須使用STUN keepalives。agent能夠通過(guò)每個(gè)媒體會(huì )話(huà)中屬性a=candidate狀態(tài)決定對端peer支持ICE。如果對端peer不支持ICE的話(huà)，keepalives數據包格式的選擇是本地部署的事情。根據RFC5245的推薦，keepalives的格式最好是這樣的格式-在實(shí)際媒體內容缺失的情況在，其格式支持數據可以非常容易發(fā)送出去。比較典型的兩個(gè)例子是RTP No-Op和RTP的舒適噪音處理。如果對端peer不支持任何目前比較采用的keepalives格式的話(huà)，agent應該使用一個(gè)不正確的版本發(fā)送RTP數據包或者其他格式發(fā)送（當然，peer可能會(huì )丟棄這些錯誤數據）。

　　在Tr秒時(shí)間內，為了一個(gè)媒體構件的處理流程，ICE使用一個(gè)候選配對發(fā)送數據，如果此候選配對中沒(méi)有數據發(fā)送，agent必須為此配對生成一個(gè)keepalives。Tr值應該是可配置的值，默認設置為15秒。Tr值一定不能低于15秒設置。另外一種處理方式是，如果agent通過(guò)動(dòng)態(tài)方式可以發(fā)現intervening NAT的綁定生命周期的話(huà)，agent可以使用這個(gè)綁定生命周期來(lái)設置Tr值。系統管理人員是在自己可控的網(wǎng)絡(luò )環(huán)境中部署ICE，在網(wǎng)絡(luò )環(huán)境允許的情況下，Tr值應該盡可能的長(cháng)一點(diǎn)。

　　如果keepalives使用了STUN，STUN綁定指示需要根據RFC5389規范來(lái)執行。此綁定指示不能使用任何認證機制。綁定指示中一個(gè)包含FINGERPRINT屬性實(shí)現多路分用，但是不能包含任何其他的屬性。此綁定指示僅用來(lái)維持NAT綁定存活處理。綁定指示通過(guò)同樣的發(fā)送媒體的本地和遠端候選地址來(lái)發(fā)送。雖然綁定指示是用來(lái)處理keepalives，但是agent仍然也需要準備好接收連接檢查。如果agent收到了一個(gè)連接檢查的話(huà)，agent應該根據RFC5389生成一個(gè)響應消息，但是，這個(gè)處理不會(huì )影響ICE的處理。

　　一旦ICE選擇了候選配對準備發(fā)送媒體流，或媒體開(kāi)始傳輸，無(wú)論以上兩種方式哪種方式首先發(fā)生，agent必須開(kāi)始keepalives的流程處理。一旦會(huì )話(huà)結束或媒體流被移除，keepalives也需要馬上結束。

　　這里需要補充一點(diǎn)關(guān)于keepalives和Voice Activity Detection （VAD）一些討論。實(shí)際環(huán)境中，keepalives 在實(shí)際數據缺失的情況下發(fā)送，所以實(shí)際環(huán)境中如果沒(méi)有使用VAD的話(huà)，從來(lái)不會(huì )產(chǎn)生keepavlives消息發(fā)送的情況，因此也不會(huì )存在帶寬增加的可能性。當啟用VAD時(shí)，keepalives消息是在靜音期發(fā)送，會(huì )在每15秒-20秒之間發(fā)送一個(gè)單數據包，此數據所占用的網(wǎng)絡(luò )資源遠小于語(yǔ)音數據發(fā)送狀態(tài)下的（每20-30毫秒之間發(fā)送）所需要的網(wǎng)絡(luò )資源。因此，keepalives的影響不會(huì )對環(huán)境部署中網(wǎng)絡(luò )帶寬有很大的影響。

　　讀者注意，因為keepalives涉及了多種網(wǎng)絡(luò )環(huán)境的連接，網(wǎng)絡(luò )設備的部署也非常復雜，簡(jiǎn)單的一種規范很難完整說(shuō)明全部的具體場(chǎng)景。筆者可以根據不同的場(chǎng)景做進(jìn)一步的研究：

　　https://tools.ietf.org/id/draft-ietf-pcp-optimize-keepalives-00.txt

　　關(guān)于keepalives的討論，一些規范和瀏覽器支持做了一些調整，讀者可以查閱筆者參考資料鏈接獲得詳情。RFC5245僅提供了ICE的keepalives的討論，讀者也可以結合RFC6263關(guān)注RTP中NAT綁定中的keepavlives的討論。

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

　　https://tools.ietf.org/id/draft-ietf-pcp-optimize-keepalives-00.txt

　　https://www.cisco.com/c/en/us/support/docs/ip/serial-tunnel-stun/16398-50.html

　　https://tools.ietf.org/html/draft-muthu-behave-consent-freshness-04

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

　　https://www.semanticscholar.org/paper/NAT-Traversal-Techniques-and-UDP-Keep-Alive-Widmer/9f730e024dd212186c7b2ced75c877edad6951f0

　　https://www.rfc-editor.org/rfc/rfc8445#section-10

　　https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39

　　融合通信/IPPBX商業(yè)解決方案：www.hiastar.com

　　最新Asterisk完整中文用戶(hù)手冊詳解及免費slack支持：www.asterisk.org.cn

　　Freepbx/FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　如何使用FreeSBC，qq技術(shù)分享群：334023047

　　關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的通信行業(yè)技術(shù)分享