特别说明，如果使用SIP协议进行协商的话，当发生SIP分叉处理时，一个单个offer可能会生成多个answer消息。在这种情况下，ICE针对每个answer进行完全独立并行处理，把这个offer和其每个answer的合并体看作一个独立的offer/answer交互模式。合并的offer/answer交互模式生成自己独立的候选配对，检查列表，状态计算等属性。其中，当释放候选地址时，这些独立的answer可能会和其他answer产生相互影响。关于这个影响的处理流程，读者可参考RFC5245-8。
下面，笔者将会按照初始应答的接收流程来一步步介绍这些具体的细节。
1、验证ICE支持能力
应答方的ICE支持能力的验证和前面笔者介绍的offer中的验证流程基本一样，一个另外就是offerer提供方从来不会在SDP中生成一个a=ice-mismatch属性。
在一些使用场景中，answer可能忽略媒体流中的a=candidate属性，但是会包含a=ice-mismatch属性，此属性用来支持一个或多个媒体流。如果是这样的设置的话，对offerer来说，answerer提供ICE支持，但是在此会话中并没有使用ICE处理流程。会话中没有使用ICE处理的原因是针对媒体构件来说，因为中间信令修改了默认目的地地址，但是没有修改相应的候选地址属性。这样的情况是完全可能发生的，可能会导致安全问题。这里涉及了关于ICE的安全问题，笔者在未来文章中会进行讨论，这里不再介绍。另外，如果类似这样的场景发生的话，RFC5245并没有提供一个明确的指导说明来说明agent如何处理这样的失败场景。
2、决定主控/被控方角色
关于应答中角色决定的处理流程，读者可以参考offer中的处理流程，流程完全一致，无特别说明。
3、构建检查列表
构建检查列表也是针对全场景部署agent来定义的，关于应答中构建检查列表的处理流程，读者可以参考offer中的处理流程，流程完全一致，无特别说明。
4、执行 ordinary checks
执行ordinary check的流程也是针对全场景部署agent来说的，读者可以参考offer中的处理流程，流程完全一致，无特别说明。
在接下来章节，笔者将讨论关于连接性检查的具体细节，包括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行业分享
Asterisk freepbx FreeSBC技术文档： www.freepbx.org.cn
融合通信/IPPBX商业解决方案：www.hiastar.com
如何使用FreeSBC，qq技术分享群：334023047
