6. 收到初始应答 (Receipt of the Initial Answer)

本节描述 agent 从 peer 收到 answer 时遵循的过程. 它会验证 peer 是否支持 ICE, 确定自身角色, 并且对于 full implementation, 形成 check list 并开始执行 ordinary checks.

当 ICE 与 SIP 一起使用时, 分叉 (forking) 可能导致单个 offer 生成多个 answer. 在这种情况下, ICE 会对每个 answer 完全并行且独立地进行, 将自身 offer 与每个 answer 的组合视为独立的 offer/answer 交换, 每个交换都有自己的 pair 集合, check list, 状态等. 一个 pair 的处理会影响另一个 pair 的唯一情形是释放 candidate, 见下文第 8.3 节.

6.1. 验证 ICE 支持 (Verifying ICE Support)

Offerer 侧的逻辑与第 5.1 节中针对 answerer 描述的逻辑相同, 唯一例外是 offerer 永远不会在 SDP 中生成 a=ice-mismatch 属性.

在某些情况下, answer 可能省略媒体流的 a=candidate 属性, 而是在 SDP 中为一个或多个媒体流包含 a=ice-mismatch 属性. 这会向 offerer 表明 answerer 支持 ICE, 但由于某个信令中介修改了媒体 component 的 default destination, 却没有修改对应的 candidate 属性, 因而本会话未使用 ICE 处理. 关于可能发生这种情况的场景, 见第 18 节. 对于 agent 在这种失败场景中应如何继续, 本规范不提供指导.

6.2. 确定角色 (Determining Role)

Offerer 遵循第 5.2 节中为 answerer 描述的相同过程.

6.3. 形成检查列表 (Forming the Check List)

只有 full implementation 执行 check list 的形成. Offerer 遵循第 5.7 节中为 answerer 描述的相同过程.

6.4. 执行普通检查 (Performing Ordinary Checks)

只有 full implementation 执行 ordinary checks. Offerer 遵循第 5.8 节中为 answerer 描述的相同过程.