14. Extensibility Considerations (拡張性に関する考慮事項)

この仕様では、セッション内の両方のエージェントが、メディア用に選択される候補ペアのセットに到達するためにどのように調整するかについて、非常に具体的な選択を行っています。将来の仕様では、タイマーの調整のような単純な変更であろうと、優先順位アルゴリズムの刷新のような大きな変更であろうと、これらのアルゴリズムを変更したいと考えることが予想されます。このような変更が行われた場合、セッション内の 2 つのエージェント間で相互運用性を提供することが重要です。

第一に、ICE は a=ice-options SDP 属性を提供します。ICE への各拡張または変更は、トークンに関連付けられています。そのような拡張または変更をサポートするエージェントがオファーまたはアンサーを生成するとき、この属性にその拡張のトークンを含めなければなりません (MUST)。これにより、各側は相手側が何をしているかを知ることができます。エージェントが ICE の拡張または変更をサポートしていない場合、この属性は存在してはなりません (MUST NOT)。

現時点では、これらのオプションタグに対して IANA レジストリまたは登録手順は定義されていません。執筆時点では、ICE の変更と拡張がレジストリを保証するほど一般的になるかどうかは不明です。

相互運用性を達成する上での複雑さの 1 つは、ICE が合意された候補ペアのセットに収束するために、両方のエージェントで実行される分散アルゴリズムに依存していることです。2 つのエージェントが異なるアルゴリズムを実行する場合、同じ候補ペアへの収束を保証することは困難な場合があります。セクション 8 で説明されている通常の指名手順は、選択アルゴリズムを完全に制御エージェントに委任することにより、緊密な調整の一部を排除します。その結果、制御エージェントが、自分が知らないオプションをサポートするピアと通信している場合、エージェントは通常の指名アルゴリズムを実行しなければなりません (MUST)。通常の指名が使用される場合、両方のエージェントが異なるペア優先順位アルゴリズムを使用しても、ICE は完全に収束します。このような収束の鍵の 1 つはトリガーチェックであり、これにより、指名されたペアが両方のエージェントによって検証されることが保証されます。したがって、将来の ICE 拡張機能はすべて、トリガーチェックを保持しなければなりません (MUST)。

ICE は、RTP 以外の他のメディアストリーム、および UDP 以外のトランスポートプロトコルにも拡張可能です。非 RTP メディアストリームの ICE 拡張機能は、利用するコンポーネントの数を指定し、最も重要なコンポーネント ID の 1 から始めて、それらにコンポーネント ID を割り当てる必要があります。新しいトランスポートプロトコルの仕様は、ICE 処理のさまざまなステップが UDP とどのように異なるか（もしあれば）を定義する必要があります。