特別說明，如果使用SIP協(xié)議進(jìn)行協(xié)商的話，當(dāng)發(fā)生SIP分叉處理時(shí)，一個(gè)單個(gè)offer可能會(huì)生成多個(gè)answer消息。在這種情況下，ICE針對(duì)每個(gè)answer進(jìn)行完全獨(dú)立并行處理，把這個(gè)offer和其每個(gè)answer的合并體看作一個(gè)獨(dú)立的offer/answer交互模式。合并的offer/answer交互模式生成自己獨(dú)立的候選配對(duì)，檢查列表，狀態(tài)計(jì)算等屬性。其中，當(dāng)釋放候選地址時(shí)，這些獨(dú)立的answer可能會(huì)和其他answer產(chǎn)生相互影響。關(guān)于這個(gè)影響的處理流程，讀者可參考RFC5245-8。
下面，筆者將會(huì)按照初始應(yīng)答的接收流程來一步步介紹這些具體的細(xì)節(jié)。
1、驗(yàn)證ICE支持能力
應(yīng)答方的ICE支持能力的驗(yàn)證和前面筆者介紹的offer中的驗(yàn)證流程基本一樣，一個(gè)另外就是offerer提供方從來不會(huì)在SDP中生成一個(gè)a=ice-mismatch屬性。
在一些使用場景中，answer可能忽略媒體流中的a=candidate屬性，但是會(huì)包含a=ice-mismatch屬性，此屬性用來支持一個(gè)或多個(gè)媒體流。如果是這樣的設(shè)置的話，對(duì)offerer來說，answerer提供ICE支持，但是在此會(huì)話中并沒有使用ICE處理流程。會(huì)話中沒有使用ICE處理的原因是針對(duì)媒體構(gòu)件來說，因?yàn)橹虚g信令修改了默認(rèn)目的地地址，但是沒有修改相應(yīng)的候選地址屬性。這樣的情況是完全可能發(fā)生的，可能會(huì)導(dǎo)致安全問題。這里涉及了關(guān)于ICE的安全問題，筆者在未來文章中會(huì)進(jìn)行討論，這里不再介紹。另外，如果類似這樣的場景發(fā)生的話，RFC5245并沒有提供一個(gè)明確的指導(dǎo)說明來說明agent如何處理這樣的失敗場景。
2、決定主控/被控方角色
關(guān)于應(yīng)答中角色決定的處理流程，讀者可以參考o(jì)ffer中的處理流程，流程完全一致，無特別說明。
3、構(gòu)建檢查列表
構(gòu)建檢查列表也是針對(duì)全場景部署agent來定義的，關(guān)于應(yīng)答中構(gòu)建檢查列表的處理流程，讀者可以參考o(jì)ffer中的處理流程，流程完全一致，無特別說明。
4、執(zhí)行 ordinary checks
執(zhí)行ordinary check的流程也是針對(duì)全場景部署agent來說的，讀者可以參考o(jì)ffer中的處理流程，流程完全一致，無特別說明。
在接下來章節(jié)，筆者將討論關(guān)于連接性檢查的具體細(xì)節(jié)，包括STUN客戶端流程流程和服務(wù)器端流程。
參考資料：
https://www.rfc-editor.org/rfc/rfc8445
https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidatePairStats/state
https://github.com/gortc/ice/blob/master/pair.go
關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
Asterisk freepbx FreeSBC技術(shù)文檔： www.freepbx.org.cn
融合通信/IPPBX商業(yè)解決方案：www.hiastar.com
如何使用FreeSBC，qq技術(shù)分享群：334023047
