Appendix A. Lite 和 Full 实现 (Lite and Full Implementations)

ICE 允许两类实现. full 实现支持会话中的 controlling 和 controlled roles, 并且还能执行地址收集. 相比之下, lite 实现是一种极简实现, 除了响应 STUN checks 之外几乎不做其他事情.

由于 ICE 要求两个 endpoints 都支持它, 才能让任一 endpoint 获得收益, 因此在网络中增量部署 ICE 更复杂. 许多会话涉及一个 endpoint, 该 endpoint 本身不在 NAT 后面, 也不会担心 NAT traversal. 一个非常常见的情况是, 一个需要 NAT traversal 的 endpoint (例如 VoIP hard phone 或 soft phone) 呼叫这类设备之一. 即使电话支持 full ICE 实现, 如果另一个设备不支持 ICE, ICE 根本不会被使用. lite 实现为这些设备提供了低成本入口点. 一旦它们支持 lite 实现, full 实现就可以连接到它们并获得 ICE 的全部收益.

因此, lite 实现只适用于那些将 始终 连接到 public Internet, 并具有 public IP address, 可在该地址上从任意 correspondent 接收分组的设备. 当 lite 实现位于 NAT 后面时, ICE 将无法工作.

ICE 允许 lite 实现具有一个 IPv4 host candidate 和若干 IPv6 地址. 在这种情况下, candidate pairs 由 controlling agent 使用静态算法选择, 例如本规范推荐的 RFC 3484 中的算法. 但是, 地址选择的静态机制总是容易出错, 因为它们永远无法反映实际拓扑, 也永远无法对连接性提供实际保证. 它们始终只是启发式方法. 因此, 如果 agent 实现 ICE 只是为了在其 IPv4 和 IPv6 地址之间进行选择, 且其所有 IP 地址都不在 NAT 后面, 仍然 推荐使用 full ICE, 以提供尽可能健壮的地址选择形式.

需要注意的是, lite 实现被加入本规范, 是为了提供通向 full 实现的垫脚石. 即便对于始终连接到 public Internet 且只有单个 IPv4 地址的设备, 如果可以实现, full 实现仍然更可取. full 实现会减少 call setup times, 因为可以使用 ICE 的 aggressive mode. full 实现还获得 ICE 中与 NAT traversal 无关的安全收益; 特别是第 18 节中描述的 voice hammer attack 只对 full 实现被防止, 对 lite 实现则不是. 最后, 一个今天拥有 public address 的设备, 明天常常可能被放入一个位于 NAT 后面的网络中. 在设备或产品的整个生命周期内, 很难明确知道它将始终在 public Internet 上使用. full 实现提供了通信始终能够工作的保证.