メインコンテンツまでスキップ

11. Receiving Trickled Candidates (トリクル候補の受信)

ICEセッション中のいつでも、Trickle ICEエージェントはリモートエージェントから新しい候補を受信する可能性があり、そこから候補ペアを形成しようとします。これはICE仕様 [RFC8445]で説明されているように機能しますが、以下の条件があります:

  1. エージェントは、同じストリームとコンポーネントに対して現在既知のローカル候補があるかどうかをチェックします。ない場合、エージェントは単に新しい候補をリモート候補のリストに追加します(ペアリングせずに)。

  2. そうでない場合、エージェントがこのストリームとコンポーネントに対して既に1つ以上のローカル候補を収集している場合、ICE仕様 [RFC8445]で説明されているように、新しいリモート候補をペアリングしようとします。

  3. 新しく形成されたペアのローカル候補のタイプがサーバー再帰 (server-reflexive)の場合、エージェントは、次のステップの冗長性チェックを完了する前に、ローカル候補をそのベースで置き換えなければなりません (MUST)。

  4. エージェントは、以下で説明するように冗長なペアを削除しますが、既存のペアをチェックするのは、それらが待機 (Waiting)状態または凍結 (Frozen)状態の場合のみです。これにより、接続性チェックが進行中のペア(進行中 (In-Progress)状態)、または接続性チェックが既に最終的な結果を出しているペア(成功 (Succeeded)状態または失敗 (Failed)状態)の削除を回避します。

    A. エージェントが2つのペア間で冗長性を見つけ、これらのペアの1つにタイプがピア再帰 (peer-reflexive)の新しく受信したリモート候補が含まれている場合、エージェントは、その候補を含むペアを拒否し、既存のペアの優先度を拒否されたペアの優先度に設定し、チェックリストを再ソートすべきです (SHOULD)。(このポリシーは、候補のシグナリングが受信エージェントにトリクルされる前にSTUNバインディング要求が受信されるリモートピア再帰候補に関する問題を排除するのに役立ちます。たとえば、ローカルエージェントとリモートエージェント間のペア優先度の異なるビューなど。同じ候補が、一方のエージェントではピア再帰として認識され、他方のエージェントではサーバー再帰として認識される可能性があるためです。)

    B. 次に、エージェントは[RFC8445]のセクション6.1.2.4で定義されたルールを適用します。

  5. 関連する冗長性テストを完了した後、ペアが追加されるチェックリストに既に候補ペアの最大数(デフォルトで[RFC8445]によると100)が含まれている場合、エージェントは、新しいペアのためのスペースを作るために、失敗状態のすべてのペアを拒否すべきです (SHOULD)。そのようなペアがない場合、エージェントは、ペアの数が最大ペア数に等しくなるまで、新しいペアのためのスペースを作るために、新しいペアよりも優先度が低いペアを拒否すべきです (SHOULD)。この処理は[RFC8445]のセクション6.1.2.5と一致しています。

に最終更新