9. Gathering and Conveying Newly Gathered Local Candidates (新しく収集されたローカル候補の収集と伝達)

Trickle ICEエージェントが初期ICE記述と初期ICE応答を送信した後、STUN、TURN、およびその他の非ホスト候補収集メカニズムが結果を生成し始めるにつれて、新しいローカル候補の収集を継続する可能性が非常に高いです。エージェントがそのような新しい候補を発見するたびに、通常のICE手順に従って、その優先順位、タイプ、基礎 (Foundation)、およびコンポーネントIDを計算します。

次に、新しい候補は、既存のローカル候補のリストに対して冗長性がチェックされます。そのトランスポートアドレスとベースが既存の候補のものと一致する場合、冗長と見なされ、無視されます。これは、取得元のホストアドレスと一致するサーバー再帰候補(例えば、後者がパブリックIPv4アドレスの場合)で頻繁に発生します。通常のICEとは異なり、Trickle ICEエージェントは、その優先順位に関係なく、新しい候補を冗長と見なします。

次に、エージェントは新しく発見された候補をリモートエージェントに「トリクル」します。新しい候補の実際の配信は、SIPやXMPPなどの使用プロトコルによって処理されます。Trickle ICEは、これがどのように行われるかについて制限を課しません(たとえば、一部の使用プロトコルは、サーバー再帰候補の更新をトリクルしないことを選択し、代わりにピア再帰候補の発見に依存する場合があります)。

候補がトリクルされる場合、使用プロトコルは、各候補(およびセクション13で説明されているような候補終了指示)を、受信側のTrickle ICE実装に、送信された順序とまったく同じ順序で正確に1回配信しなければなりません (MUST)。使用プロトコルが候補の再送信を提供する場合、それらはICE実装から隠されなければなりません。

さらに、候補のトリクリングは特定のICEセッションに関連付けられなければならず、ICE再起動がある場合、以前のセッションの遅延更新がそのようなものとして認識され、受信側によって無視されるようにする必要があります。たとえば、SDPを介して候補を通知する使用プロトコルは、対応するa=candidate行にUsername Fragment値を含めることができます:

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

または、別の例として、WebRTC実装は、候補を表すJavaScriptオブジェクトにUsername Fragmentを含めることができます。

注:使用プロトコルは、両方の当事者が有効なICEセッション(Username FragmentとPasswordの組み合わせによって識別される)を示して合意するためのメカニズムを提供しなければならず、候補をペアリングするための一貫したビューを持つようにする必要があります。これは、ICE再起動の場合に特に重要です(セクション15を参照)。

注:使用プロトコルは、公開アクセス可能であることがわかっているエンティティに対してサーバー再帰候補をトリクルしないことを選択する場合があります。この場合、直接STUNバインディング要求を送信すると、シグナリングパスを通過するトリクル更新よりも速く宛先に到達する可能性が高いためです。