欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當(dāng)前的位置是:  首頁 > 資訊 > 國內(nèi) >
 首頁 > 資訊 > 國內(nèi) >

完整SIP/SDP媒體協(xié)商概論-ICE選項(xiàng)和keepalives討論

2020-05-12 09:09:43   作者: james.zhu   來源:Asterisk開源派   評論:0  點(diǎn)擊:


  筆者在前面的完整介紹了關(guān)于后續(xù)offer/answer交互過程中offer接收和answer生成的細(xì)節(jié)。這里,筆者將介紹后續(xù)offer/answer交互中的最后一個部分-ICE選項(xiàng)支持,狀態(tài)更新以及存活時間的討論。在更新狀態(tài)中又涉及了全場景部署的處理流程和輕量級場景的部署流程,F(xiàn)在,我們逐一介紹這些細(xì)節(jié)。
  1、全場景部署處理流程
  在全場景部署的更新處理流程中涉及了四個方面的內(nèi)容需要討論。首先,我們介紹一下關(guān)于ICE重新啟動的內(nèi)容。
  在ICE重新啟動之前,針對媒體流的每個構(gòu)件,agent必須記住在有效列表中的最高優(yōu)先級標(biāo)識的配對(稱之為歷史已選配對)。Agent將會繼續(xù)使用這些配對發(fā)送媒體流。發(fā)送媒體流的流程在后面的文章中會加以討論。一旦目的地地址收到提示信息,agent必須刷新有效列表和檢查列表中的數(shù)據(jù)。然后agent重新計(jì)算檢查列表和其狀態(tài)。具體處理流程參考?xì)v史文章中關(guān)于構(gòu)建檢查列表的流程。
  如果在offer/answer交互中已添加了一個新的媒體流,agent必須為此新媒體流創(chuàng)建一個新的檢查列表,還創(chuàng)建一個新的初始為空的有效列表。具體處理流程參考?xì)v史文章中關(guān)于構(gòu)建檢查列表的流程。
  如果在offer/answer交互要移除一個媒體流或answer拒絕了offer中提供的媒體流的話,agent必須為此媒體流刷新有效列表,必須結(jié)束在任何處理過程的STUN事務(wù)。agent必須為此媒體流移除檢查列表,并且取消任何待處理的ordinary checks。
  針對全場景部署中的更新有效列表和檢查列表,ICE的處理根據(jù)agent的狀態(tài)和檢查列表狀態(tài)的不同存在很多不同流程。首先說明,除非正在ICE重新啟動,否則有效列表是不會受更新offer/answer交互影響。
  針對一個媒體流來說,如果agent的狀態(tài)是正在運(yùn)行狀態(tài),檢查列表是已更新狀態(tài)(如果狀態(tài)是完成狀態(tài),檢查列表已無相關(guān)性)。為了實(shí)現(xiàn)這個要求,agent必須使用計(jì)算流程重新計(jì)算檢查列表。具體處理流程參考?xì)v史文章中關(guān)于構(gòu)建檢查列表的流程。在計(jì)算結(jié)果中,如果發(fā)現(xiàn)在檢查列表中有一對配對已經(jīng)是全面檢查列表中出現(xiàn)的配對的話,其配對狀態(tài)是Waiting,In-Progress,Succeeded或Failed狀態(tài)的話,其狀態(tài)將被拷貝到檢查列表中;否則其狀態(tài)將設(shè)置為封凍狀態(tài)(Frozen)。
  如果檢查列表中無任何活動配對(意味著每個檢查列表中的配對是封凍狀態(tài)),full-mode(雙方agent都使用了ICE)的 agent為第一個媒體流在有效列表中設(shè)置第一個配對,設(shè)置的第一個配對的狀態(tài)為等待狀態(tài),然后把在檢查列表中具有同樣component ID和具有同樣foundation所有其他配對設(shè)置為等待狀態(tài)。
  接下來,agent會逐一執(zhí)行某個檢查列表,最高優(yōu)先級的配對首先開始執(zhí)行。如果列表中有一個配對狀態(tài)是成功狀態(tài),其component ID設(shè)置為1,然后繼續(xù)執(zhí)行以下處理。在同樣檢查列表中,如果所有其他封凍狀態(tài)的配對具有同樣foundation,并且在這些具有同樣foundation配對中,如果它們的component ID不是1的話,agent將把這些封凍的配對的狀態(tài)設(shè)置為等待狀態(tài)。針對一個具體的檢查列表,如果媒體流的每個構(gòu)件的配對有一對在成功狀態(tài),為其他所有媒體流的第一個構(gòu)件(可能在不同的檢查列表中),agent將會把所有具有同樣foundation,其配對狀態(tài)處于封凍狀態(tài)的配對的狀態(tài)進(jìn)行狀態(tài)遷移,這些配對的狀態(tài)從封凍狀態(tài)設(shè)置為等待狀態(tài)。
  2、輕量級場景部署場景
  輕量級的部署場景中關(guān)于更新列表檢查的處理比較簡單。如果為一個媒體流重新啟動ICE,agent也必須為此媒體流重新啟動一個有效列表。Agent也必須記得此媒體流的每個構(gòu)件的上次有效列表中的配對(稱之為歷史已選配對)。然后根據(jù)流程繼續(xù)發(fā)送媒體流。流程的規(guī)則定義在將來的文章中介紹。接下來,針對每個媒體流的ICE處理狀態(tài)必須修改為正在運(yùn)行狀態(tài)。
  3、ICE option標(biāo)識
  在實(shí)際應(yīng)用場景中,我們經(jīng)常遇到一些用戶的反饋WebRTC的兼容性問題,自己也經(jīng)常面臨WebRTC的兼容性問題。我們不得不經(jīng)常更新一些功能支持,同時也不得不不斷學(xué)習(xí)新的知識。其實(shí),我們從RFC5245以及其最新規(guī)范8445中就可以看出,這些處理流程在最近幾年內(nèi)進(jìn)行了很多次修改,F(xiàn)在,我們介紹一個特殊的ICE選項(xiàng)。除了在RFC5245中規(guī)定的ICE啟動流程以外,在最新的RFC8445中增加了一個ICE選項(xiàng)-ice2 選項(xiàng)。當(dāng)ICE agent在候選交互中包含了ice2選項(xiàng)以后,表示需要遵從RFC8445規(guī)范。在一些特定的交互中使用ice2讓對端peer獲悉agent也不再使用此交互流程。例如,在RFC8445中已經(jīng)移除了主動推薦標(biāo)識的流程(aggressive nomination procedure),如果agent需要通知對端不再使用此交互流程時,可以增加一個ice2選項(xiàng)來表示。
  一個agent如果遵從RFC8445的話,在候選地址交互開始時必須通過ice2通知對端peer其交互模式啟用了ice2選項(xiàng)。否則,對端可能收到一個未知的ice選項(xiàng)。
  關(guān)于對ice2的編碼和對對端peer的消息傳輸,讀者可以參與RFC4566中的參考規(guī)范。在其參考規(guī)范中詳細(xì)說明了ICE-SIP-SDP的細(xì)節(jié)。最新的草案參考鏈接如下:
  ice-sip-sdp:
  https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39
  另外,再次提醒讀者,如果要開發(fā)最新的SIP和WebRTC的業(yè)務(wù)應(yīng)用的話,因?yàn)镮CE處理流程中SDP的頻繁更迭,讀者一定要關(guān)注最新的RFC8445規(guī)范以及關(guān)于SDP構(gòu)建的草案。
  4、Keepalives
  無論是否使用ICE或者媒體流的狀態(tài)如何,keepalives是終端保持存活的重要手段。大家知道,為了終端保持狀態(tài)的活動狀態(tài),所有的終端都必須不斷向服務(wù)器端發(fā)送存活消息。針對媒體會話來說,存活消息的目的就是為了保持NAT綁定存活狀態(tài)。無論媒體流狀態(tài)是inactive,sendonly,recvonly還是sendrecv狀態(tài),并且也不管在線狀態(tài),帶寬屬性設(shè)置狀態(tài),終端必須發(fā)送keepalives。即使周期會話中完全沒有使用ICE,終端也必須發(fā)送keepalives。終端應(yīng)該使用對端peer能夠支持的格式來發(fā)送keepalives。ICE終端允許基于STUN的keepalives支持UDP的流。具體來說,當(dāng)agent是一個全場景部署的agent,并且和對端peer(輕量級部署場景或全場景部署agent)通信時,它們之間必須使用STUN keepalives。agent能夠通過每個媒體會話中屬性a=candidate狀態(tài)決定對端peer支持ICE。如果對端peer不支持ICE的話,keepalives數(shù)據(jù)包格式的選擇是本地部署的事情。根據(jù)RFC5245的推薦,keepalives的格式最好是這樣的格式-在實(shí)際媒體內(nèi)容缺失的情況在,其格式支持?jǐn)?shù)據(jù)可以非常容易發(fā)送出去。比較典型的兩個例子是RTP No-Op和RTP的舒適噪音處理。如果對端peer不支持任何目前比較采用的keepalives格式的話,agent應(yīng)該使用一個不正確的版本發(fā)送RTP數(shù)據(jù)包或者其他格式發(fā)送(當(dāng)然,peer可能會丟棄這些錯誤數(shù)據(jù))。
  在Tr秒時間內(nèi),為了一個媒體構(gòu)件的處理流程,ICE使用一個候選配對發(fā)送數(shù)據(jù),如果此候選配對中沒有數(shù)據(jù)發(fā)送,agent必須為此配對生成一個keepalives。Tr值應(yīng)該是可配置的值,默認(rèn)設(shè)置為15秒。Tr值一定不能低于15秒設(shè)置。另外一種處理方式是,如果agent通過動態(tài)方式可以發(fā)現(xiàn)intervening NAT的綁定生命周期的話,agent可以使用這個綁定生命周期來設(shè)置Tr值。系統(tǒng)管理人員是在自己可控的網(wǎng)絡(luò)環(huán)境中部署ICE,在網(wǎng)絡(luò)環(huán)境允許的情況下,Tr值應(yīng)該盡可能的長一點(diǎn)。
  如果keepalives使用了STUN,STUN綁定指示需要根據(jù)RFC5389規(guī)范來執(zhí)行。此綁定指示不能使用任何認(rèn)證機(jī)制。綁定指示中一個包含F(xiàn)INGERPRINT屬性實(shí)現(xiàn)多路分用,但是不能包含任何其他的屬性。此綁定指示僅用來維持NAT綁定存活處理。綁定指示通過同樣的發(fā)送媒體的本地和遠(yuǎn)端候選地址來發(fā)送。雖然綁定指示是用來處理keepalives,但是agent仍然也需要準(zhǔn)備好接收連接檢查。如果agent收到了一個連接檢查的話,agent應(yīng)該根據(jù)RFC5389生成一個響應(yīng)消息,但是,這個處理不會影響ICE的處理。
  一旦ICE選擇了候選配對準(zhǔn)備發(fā)送媒體流,或媒體開始傳輸,無論以上兩種方式哪種方式首先發(fā)生,agent必須開始keepalives的流程處理。一旦會話結(jié)束或媒體流被移除,keepalives也需要馬上結(jié)束。
  這里需要補(bǔ)充一點(diǎn)關(guān)于keepalives和Voice Activity Detection (VAD)一些討論。實(shí)際環(huán)境中,keepalives 在實(shí)際數(shù)據(jù)缺失的情況下發(fā)送,所以實(shí)際環(huán)境中如果沒有使用VAD的話,從來不會產(chǎn)生keepavlives消息發(fā)送的情況,因此也不會存在帶寬增加的可能性。當(dāng)啟用VAD時,keepalives消息是在靜音期發(fā)送,會在每15秒-20秒之間發(fā)送一個單數(shù)據(jù)包,此數(shù)據(jù)所占用的網(wǎng)絡(luò)資源遠(yuǎn)小于語音數(shù)據(jù)發(fā)送狀態(tài)下的(每20-30毫秒之間發(fā)送)所需要的網(wǎng)絡(luò)資源。因此,keepalives的影響不會對環(huán)境部署中網(wǎng)絡(luò)帶寬有很大的影響。
  讀者注意,因?yàn)閗eepalives涉及了多種網(wǎng)絡(luò)環(huán)境的連接,網(wǎng)絡(luò)設(shè)備的部署也非常復(fù)雜,簡單的一種規(guī)范很難完整說明全部的具體場景。筆者可以根據(jù)不同的場景做進(jìn)一步的研究:
  關(guān)于keepalives的優(yōu)化,讀者可以查閱草案的3.4章節(jié):
  https://tools.ietf.org/id/draft-ietf-pcp-optimize-keepalives-00.txt
  關(guān)于keepalives的討論,一些規(guī)范和瀏覽器支持做了一些調(diào)整,讀者可以查閱筆者參考資料鏈接獲得詳情。RFC5245僅提供了ICE的keepalives的討論,讀者也可以結(jié)合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完整中文用戶手冊詳解及免費(fèi)slack支持:www.asterisk.org.cn
  Freepbx/FreeSBC技術(shù)文檔: www.freepbx.org.cn
  如何使用FreeSBC,qq技術(shù)分享群:334023047
  關(guān)注微信公眾號:asterisk-cn,獲得有價值的通信行業(yè)技術(shù)分享
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn),與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點(diǎn)判斷保持中立,不對所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔(dān)全部責(zé)任。

相關(guān)閱讀:

專題

CTI論壇會員企業(yè)