　　此文章將討論agent的應(yīng)答接收流程。agent收到應(yīng)答從遠端peer以后，它需要按照一定的流程來進行處理。具體的處理流程包括驗證ICE支持能力，決定雙方的角色，構(gòu)建檢查列表，最后執(zhí)行ordinary checks。

　　特別說明，如果使用SIP協(xié)議進行協(xié)商的話，當(dāng)發(fā)生SIP分叉處理時，一個單個offer可能會生成多個answer消息。在這種情況下，ICE針對每個answer進行完全獨立并行處理，把這個offer和其每個answer的合并體看作一個獨立的offer/answer交互模式。合并的offer/answer交互模式生成自己獨立的候選配對，檢查列表，狀態(tài)計算等屬性。其中，當(dāng)釋放候選地址時，這些獨立的answer可能會和其他answer產(chǎn)生相互影響。關(guān)于這個影響的處理流程，讀者可參考RFC5245-8。

　　下面，筆者將會按照初始應(yīng)答的接收流程來一步步介紹這些具體的細節(jié)。

　　1、驗證ICE支持能力

　　應(yīng)答方的ICE支持能力的驗證和前面筆者介紹的offer中的驗證流程基本一樣，一個另外就是offerer提供方從來不會在SDP中生成一個a=ice-mismatch屬性。

　　在一些使用場景中，answer可能忽略媒體流中的a=candidate屬性，但是會包含a=ice-mismatch屬性，此屬性用來支持一個或多個媒體流。如果是這樣的設(shè)置的話，對offerer來說，answerer提供ICE支持，但是在此會話中并沒有使用ICE處理流程。會話中沒有使用ICE處理的原因是針對媒體構(gòu)件來說，因為中間信令修改了默認目的地地址，但是沒有修改相應(yīng)的候選地址屬性。這樣的情況是完全可能發(fā)生的，可能會導(dǎo)致安全問題。這里涉及了關(guān)于ICE的安全問題，筆者在未來文章中會進行討論，這里不再介紹。另外，如果類似這樣的場景發(fā)生的話，RFC5245并沒有提供一個明確的指導(dǎo)說明來說明agent如何處理這樣的失敗場景。

　　2、決定主控/被控方角色

　　關(guān)于應(yīng)答中角色決定的處理流程，讀者可以參考offer中的處理流程，流程完全一致，無特別說明。

　　3、構(gòu)建檢查列表

　　構(gòu)建檢查列表也是針對全場景部署agent來定義的，關(guān)于應(yīng)答中構(gòu)建檢查列表的處理流程，讀者可以參考offer中的處理流程，流程完全一致，無特別說明。

　　4、執(zhí)行 ordinary checks

　　執(zhí)行ordinary check的流程也是針對全場景部署agent來說的，讀者可以參考offer中的處理流程，流程完全一致，無特別說明。

　　在接下來章節(jié)，筆者將討論關(guān)于連接性檢查的具體細節(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