5. ICE Candidate Gathering and Exchange (ICE候选收集和交换)

作为ICE处理的一部分, 发起代理和响应代理都会收集候选、确定优先级并消除冗余候选, 并按照使用协议 (ICE用法) 的定义与对等方交换候选信息。候选编码机制和候选信息交换语义的细节不在本规范的范围内。

5.1. Full Implementation (完整实现)

5.1.1. Gathering Candidates (收集候选)

ICE代理在认为通信即将发生时收集候选。发起代理可以基于用户界面提示或启动会话的显式请求来执行此操作。每个候选都有一个传输地址。它还有一个类型和一个基础。本规范定义并收集了四种类型 -- 主机候选 (host candidates)、服务器反射候选 (server-reflexive candidates)、对等反射候选 (peer-reflexive candidates) 和中继候选 (relayed candidates)。服务器反射候选使用STUN或TURN收集, 中继候选通过TURN获得。对等反射候选在ICE的后期阶段作为连通性检查的结果获得。

响应代理收集候选的过程与发起代理的过程相同。建议 (RECOMMENDED) 响应代理在收到候选信息后立即开始此过程, 在向与ICE会话关联的应用程序的用户发出警报之前。

5.1.1.1. Host Candidates (主机候选)

主机候选通过绑定到主机上连接到接口 (物理或虚拟, 包括VPN接口) 的IP地址上的端口来获得。

对于ICE代理希望使用的每个数据流的每个组件, 代理应该 (SHOULD) 在主机拥有的每个IP地址上获得一个候选, 但下面列出的例外情况除外。代理通过绑定到特定IP地址上的UDP端口来获得每个候选。主机候选 (实际上是每个候选) 始终与它作为候选的特定组件相关联。

每个组件都分配了一个ID, 称为"组件ID (component ID)"。对于RTP/RTCP数据流, 除非RTP和RTCP在同一UDP端口上多路复用 (RTP/RTCP多路复用), 否则RTP本身的组件ID为1, RTCP的组件ID为2。在RTP/RTCP多路复用的情况下, RTP和RTCP都使用组件ID 1。

当获得候选时, 除非代理确定将使用RTP/RTCP多路复用 (即, 代理知道另一个代理也支持并愿意使用RTP/RTCP多路复用), 或者除非代理仅支持RTP/RTCP多路复用, 否则代理必须 (MUST) 为RTCP获得单独的候选。如果代理已为RTCP获得候选, 并最终使用RTP/RTCP多路复用, 则代理不需要对RTCP候选执行连通性检查。缺少组件ID 2本身并不意味着使用RTCP/RTP多路复用, 因为它也可能意味着不使用RTCP。

如果代理为RTP和RTCP使用单独的候选, 如果代理有K个IP地址, 它将最终拥有2*K个主机候选。

请注意, 响应代理在获得其候选时, 通常会知道另一个代理是否支持RTP/RTCP多路复用, 在这种情况下, 它不需要为RTCP获得单独的候选。但是, 缺少组件ID 2本身并不意味着使用RTCP/RTP多路复用, 因为它也可能意味着不使用RTCP。

不鼓励使用多个组件 (除了RTP/RTCP流之外), 因为这会增加ICE处理的复杂性。如果需要多个组件, 组件ID应该 (SHOULD) 从1开始, 并为每个组件增加1。

---