14. 可扩展性考虑 (Extensibility Considerations)

本规范对会话中两个 agents 如何协调并得出被选用于媒体的 candidate pairs 集合作出了非常具体的选择. 预计未来规范会希望修改这些算法, 无论是像调整定时器这样的小改动, 还是像重构优先级算法这样的大改动. 当作出此类变更时, 在会话中的两个 agents 之间提供互操作性至关重要.

首先, ICE 提供 a=ice-options SDP 属性. ICE 的每个扩展或变更都与一个 token 关联. 当支持此类扩展或变更的 agent 生成 offer 或 answer 时, 它 必须在该属性中包含此扩展的 token. 这允许每一端知道另一端正在做什么. 如果 agent 不支持任何 ICE 扩展或变更, 则该属性 不得出现.

目前, 没有为这些 option tags 定义 IANA registry 或注册过程. 在撰写本文时, 尚不清楚 ICE 变更和扩展是否会足够常见, 以致需要一个 registry.

实现互操作性的复杂之处在于, ICE 依赖两个 agents 上运行的分布式算法, 以收敛到一组共同认可的 candidate pairs. 如果两个 agents 运行不同算法, 可能很难保证收敛到相同的 candidate pairs. 第 8 节描述的 regular nomination 过程通过将选择算法完全委托给 controlling agent, 消除了部分紧密协调需求. 因此, 当 controlling agent 与支持其未知 options 的对等方通信时, 该 agent 必须运行 regular nomination algorithm. 使用 regular nomination 时, 即便两个 agents 使用不同的 pair priority 算法, ICE 也会完全收敛. 这种收敛的关键之一是 triggered checks, 它确保 nominated pair 被两个 agents 验证. 因此, 任何未来的 ICE 增强都 必须保留 triggered checks.

ICE 还可扩展到 RTP 之外的其他媒体流, 以及 UDP 之外的其他 transport protocols. 面向非 RTP 媒体流的 ICE 扩展需要说明它们使用多少个 components, 并为其分配 component IDs, 从最重要的 component ID 1 开始. 新 transport protocols 的规范必须定义 ICE 处理中的各个步骤与 UDP 有何不同, 如果存在差异的话.