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

10. Pairing Newly Gathered Local Candidates (新しく収集されたローカル候補のペアリング)

Trickle ICEエージェントがローカル候補を収集する際、候補ペアを形成しなければなりません。これはICE仕様 [RFC8445]で説明されているように機能しますが、以下の条件があります:

  1. Trickle ICEエージェントは、ローカル候補がリモート側にトリクルされるまで、ローカル候補をペアリングしてはなりません (MUST NOT)。

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

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

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

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

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

に最終更新