5. ICE Candidate 收集和交换
作为 ICE 处理的一部分, 发起 agent 和响应 agent 都会收集 candidate, 为 candidate 确定优先级并消除冗余 candidate, 然后按照 using protocol (ICE usage) 的定义与对等方交换 candidate 信息. Candidate 编码机制的细节以及 candidate 信息交换的语义超出了本规范的范围.
5.1. 完整实现
5.1.1. 收集 Candidate
当 ICE agent 认为通信即将发生时, 它会收集 candidate. 发起 agent 可以基于用户界面提示或显式的会话发起请求来执行此操作. 每个 candidate 都有一个传输地址. 它还具有 type 和 base. 本规范定义并收集四种类型 -- host candidate, server-reflexive candidate, peer-reflexive candidate, 和 relayed candidate. Server-reflexive candidate 使用 STUN 或 TURN 收集, relayed candidate 通过 TURN 获得. Peer-reflexive candidate 在 ICE 的后续阶段中作为 connectivity check 的结果获得.
响应 agent 收集 candidate 的过程与发起 agent 的过程相同. RECOMMENDED 响应 agent 在收到 candidate 信息后立即开始此过程, 先于通知与 ICE 会话关联的应用用户.
5.1.1.1. Host Candidate
Host candidate 通过绑定到主机上某个接口 (物理或虚拟, 包括 VPN 接口) 所附加 IP 地址的端口来获得.
对于 ICE agent 希望使用的每个数据流的每个 component, 除下文列出的例外情况外, agent SHOULD 在主机拥有的每个 IP 地址上获得一个 candidate. Agent 通过在特定 IP 地址上绑定 UDP 端口来获得每个 candidate. Host candidate (实际上每个 candidate 都是如此) 总是与其所对应的特定 component 关联.
每个 component 都有一个分配给它的 ID, 称为 "component ID". 对于 RTP/RTCP 数据流, 除非 RTP 和 RTCP 复用在同一个 UDP 端口上 (RTP/RTCP multiplexing), 否则 RTP 本身的 component ID 为 1, RTCP 的 component ID 为 2. 在 RTP/RTCP multiplexing 的情况下, RTP 和 RTCP 都使用 component ID 1.
5.1.1.2. Server-Reflexive 和 Relayed Candidate
Agent SHOULD 获得 server-reflexive candidate 和 relayed candidate. 但是, 在某些网络中使用 STUN 和 TURN 服务器可能没有必要, 并且使用 TURN 服务器可能成本较高, 因此某些部署可能认为不需要使用 TURN 服务器.