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