跳到主要内容

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 描述的相同过程.