3.5.4. ICE Candidate Pool (ICE 候选池)

3.5.4. ICE Candidate Pool (ICE 候选池)

JSEP 应用程序通常通过提供给 setLocalDescription 的信息通知 JSEP 实现开始 ICE 收集, 因为本地描述指示将需要的 ICE 组件数量以及必须为其收集候选的数量。然而, 为了加速应用程序提前知道要使用的 ICE 组件数量的情况, 它可以要求实现收集潜在 ICE 候选池, 以帮助确保快速的媒体设置。

当最终调用 setLocalDescription 并且 JSEP 实现准备收集所需的 ICE 候选时, 它应该首先检查池中是否有可用的候选。如果池中有候选, 则应该通过 ICE 候选事件立即将它们交给应用程序。如果池耗尽, 无论是因为使用了比预期更多的 ICE 组件, 还是因为池没有足够的时间收集候选, 其余候选将照常收集。这仅在第一次 offer/answer 交换时发生, 之后候选池被清空并不再使用。

这个概念有用的一个例子是, 应用程序预期在未来某个时刻会有来电, 并希望最小化建立连接所需的时间, 以避免初始媒体的剪切。通过将候选预先收集到池中, 它可以在收到呼叫后几乎立即交换并开始从这些候选发送连接性检查。但请注意, 通过保留这些预先收集的候选 (只要可能需要它们就会保持活动状态), 应用程序将消耗其正在使用的 STUN/TURN 服务器上的资源。("STUN" 代表 "Session Traversal Utilities for NAT", 即 NAT 会话遍历实用程序)。