9. 收集和传递新收集的本地候选地址 (Gathering and Conveying Newly Gathered Local Candidates)

在Trickle ICE代理传递了初始ICE描述和初始ICE响应之后，它们很可能会继续收集新的本地候选地址，因为STUN、TURN和其他非主机候选地址收集机制开始产生结果。每当代理发现这样的新候选地址时，它将根据常规ICE程序计算其优先级、类型、基础 (foundation) 和组件ID。

然后根据现有本地候选地址列表检查新候选地址的冗余性。如果其传输地址和基础与现有候选地址的传输地址和基础匹配，则将其视为冗余并将被忽略。这通常会发生在服务器反射候选地址 (server-reflexive candidates) 与从中获得的主机地址匹配的情况下 (例如，当后者是公共IPv4地址时)。与常规ICE相反，Trickle ICE代理将认为新候选地址是冗余的，无论其优先级如何。

接下来，代理将新发现的候选地址"逐步传递"给远程代理。新候选地址的实际传递由使用协议 (如SIP或XMPP) 处理。Trickle ICE对此的执行方式不施加限制 (例如，某些使用协议可能选择不逐步传递服务器反射候选地址的更新，而是依赖于发现对等反射候选地址 (peer-reflexive candidates))。

当候选地址被逐步传递时，使用协议必须 (MUST) 将每个候选地址 (以及如第13节所述的任何候选地址结束指示) 恰好传递一次给接收的Trickle ICE实现，并且按照传递的相同顺序。如果使用协议提供任何候选地址重传，则需要对ICE实现隐藏它们。

此外，候选地址逐步传递需要与特定的ICE会话相关联，以便如果有ICE重启，可以识别先前会话的任何延迟更新并由接收方忽略。例如，通过SDP传递候选地址的使用协议可能在相应的a=candidate行中包含用户名片段值，例如:

  a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY

或者，作为另一个示例，WebRTC实现可能在表示候选地址的JavaScript对象中包含用户名片段。

注意: 使用协议需要提供一种机制，以便双方指示并就生效的ICE会话 (由用户名片段和密码组合标识) 达成一致，以便它们对哪些候选地址要配对有一致的看法。这在ICE重启的情况下尤为重要 (见第15节)。

注意: 使用协议可能更倾向于不将服务器反射候选地址逐步传递给已知可公开访问的实体，在这些实体中发送直接STUN绑定请求可能比通过信令路径传递的逐步传递更新更快到达目的地。