8. Concluding ICE Processing (ICE 処理の終了)

このセクションでは、エージェントが ICE を完了する方法について説明します。

8.1. Procedures for Full Implementations (完全な実装の手順)

ICE の終了には、制御エージェントによるペアの指名と状態マシンの更新が含まれます。

8.1.1. Nominating Pairs (ペアの指名)

制御エージェントは、通常指名または積極的指名の 2 つの手法のうちの 1 つを使用して、ICE によって選択されるペアを指名します。ピアが Lite 実装の場合、エージェントは通常指名アルゴリズムを使用しなければなりません (MUST)。ピアがエージェントが理解できない ICE オプション（ピアからの ice-options 属性に存在）を使用している場合、エージェントは通常指名アルゴリズムを使用しなければなりません (MUST)。ピアが完全な実装であり、ICE オプションを使用していないか、エージェントが理解できる ICE オプションを使用している場合、エージェントは積極的指名アルゴリズムまたは通常指名アルゴリズムのいずれかを使用してもよいです (MAY)。ただし、通常アルゴリズムはより高い安定性を提供するため、推奨されます (RECOMMENDED)。

8.1.1.1. Regular Nomination (通常指名)

通常指名では、エージェントはいくつかのチェックを完了させ、そのそれぞれで USE-CANDIDATE 属性を省略します。メディアストリームのコンポーネントに対して 1 つ以上のチェックが正常に完了すると、有効なペアが生成され、有効リストに追加されます。エージェントは、いくつかの停止基準が満たされるまでチェックを継続させ、その後、評価基準に基づいて有効なペアの中から選択します。チェックを停止するための基準と有効なペアを評価するための基準は、完全にローカル最適化の問題です。

制御エージェントが有効なペアを選択すると、この有効なペアを生成したチェックを繰り返します（チェックを生成したペアをトリガーチェックキューに追加することによって）。今回は USE-CANDIDATE 属性を使用します。このチェックは成功するはずであり（以前のチェックが成功したため）、そのペアのみの指名フラグが設定されます。その結果、各コンポーネントの有効リストには指名されたペアが 1 つだけ存在し、チェックリストの状態が完了に移行すると、ICE はそのコンポーネントのメディアの送受信にその正確なペアを選択します。

通常指名は、エージェントがチェックの停止および選択基準を制御できるため、最も柔軟性があります。唯一の要件は、エージェントが最終的に 1 つだけ候補ペアを選択し、USE-CANDIDATE 属性が存在するそのペアのチェックを生成しなければならないことです (MUST)。通常指名は、実装のばらつきに対する ICE の回復力も向上させます（セクション 14 を参照）。通常指名はより安定的であり、積極的アルゴリズムで発生する可能性のある一時的な選択なしに、両方のエージェントがメディア用の単一のペアに収束できるようにします。通常指名の欠点は、追加のチェックを行う必要があるため、レイテンシが増加することが保証されることです。

8.1.1.2. Aggressive Nomination (積極的指名)

積極的指名では、制御エージェントは送信するすべてのチェックに USE-CANDIDATE 属性を含めます。コンポーネントの最初のチェックが成功すると、有効リストに追加され、指名フラグが設定されます。すべてのコンポーネントが有効リストに指名されたペアを持つと、最も優先度の高い指名されたペアを使用してメディアのフローを開始できます。ただし、エージェントはすべてのチェックに USE-CANDIDATE 属性を含めたため、別のチェックがまだ完了し、別の有効なペアの指名フラグが設定される可能性があります。ICE は常に、有効リストから最も優先度の高い指名された候補ペアをメディアに使用するものとして選択します。その結果、ICE チェックが完了するにつれて、選択されたペアが実際に短時間変更される可能性があり、安定するまで一連の一時的な選択が発生します。

8.1.2. Updating States (状態の更新)

制御エージェントと被制御エージェントの両方について、ICE 処理の状態は、有効リスト内の指名された候補ペアの存在とチェックリストの状態に依存します。いつでも、次のケースの複数が適用される可能性があることに注意してください。

• メディアストリームの有効リストに指名されたペアがなく、チェックリストの状態が Running の場合、ICE 処理は継続します。

• メディアストリームの有効リストに少なくとも 1 つの指名されたペアがあり、チェックリストの状態が Running の場合：

  • エージェントは、そのメディアストリームの指名されたペアと同じコンポーネントのチェックリストおよびトリガーチェックキュー内のすべての Waiting および Frozen ペアを削除しなければなりません (MUST)。

  • チェックリスト内の In-Progress ペアが指名されたペアと同じコンポーネント用である場合、そのペアの優先度がそのコンポーネントの最も優先度の低い指名されたペアよりも低い場合、エージェントはそのチェックの再送信を停止すべきです (SHOULD)。

• 少なくとも 1 つのメディアストリームのすべてのコンポーネントについて有効リストに少なくとも 1 つの指名されたペアがあり、チェックリストの状態が Running になると：

  • エージェントは、そのメディアストリームのチェックリストの処理状態を Completed に変更しなければなりません (MUST)。

  • エージェントは、そのメディアストリームに対してまだ受信する可能性のあるチェックに応答し続けなければならず (MUST)、セクション 7.2 の処理で必要な場合はトリガーチェックを実行しなければなりません (MUST)。

  • エージェントは、そのチェックリストの In-Progress チェックの再送信を継続しなければなりません (MUST)。

  • エージェントは、セクション 11.1 で説明されているように、このメディアストリームのメディア送信を開始してもよいです (MAY)。

• 各チェックリストの状態が Completed になると：

  • エージェントは、ICE 処理全体の状態を Completed に設定します。

  • エージェントが制御側である場合、各メディアストリームの各コンポーネントについて、最も優先度の高い指名された候補ペアを調べます。それらの候補ペアのいずれかが最新のオファー/アンサー交換のデフォルトの候補ペアと異なる場合、制御エージェントはセクション 9 で説明されているように更新されたオファーを生成しなければなりません (MUST)。制御エージェントが積極的指名アルゴリズムを使用している場合、メディア用に選択されたペアが変更されるにつれて、複数の更新されたオファーが発生する可能性があります。エージェントは、選択されたペアが安定するように、短い間隔（1 秒が推奨 (RECOMMENDED)）だけオファーの送信を遅らせてもよいです (MAY)。

• チェックリストの状態が Failed の場合、ICE はこのメディアストリームに対して完了できませんでした。正しい動作は、他のメディアストリームのチェックリストの状態によって異なります。

  • すべてのチェックリストが Failed の場合、ICE 処理全体が Failed 状態にあると見なされ、エージェントはセッションを失敗と見なすべきであり (SHOULD)、ICE を再開すべきではなく (SHOULD NOT)、制御エージェントはセッション全体を終了すべきです (SHOULD)。

  • 他のメディアストリームのチェックリストの少なくとも 1 つが Completed の場合、制御エージェントは更新されたオファーでセッションから失敗したメディアストリームを削除すべきです (SHOULD)。

  • 他のメディアストリームのチェックリストのいずれも Completed ではないが、少なくとも 1 つが Running の場合、エージェントは ICE を継続させるべきです (SHOULD)。

8.2. Procedures for Lite Implementations (Lite 実装の手順)

Lite 実装の ICE の終了は比較的簡単です。考慮すべき 2 つのケースがあります。

実装は Lite で、ピアは Full です。

実装は Lite で、ピアは Lite です。

ICE 終了の効果は、セクション 8.3 で説明されているように、エージェントが ICE によって使用されなかった割り当て済みのホスト候補を解放できることです。

8.2.1. Peer Is Full (ピアは Full)

この場合、エージェントはピアから接続チェックを受信します。エージェントがメディアストリームの各コンポーネントに対して USE-CANDIDATE 属性を含む接続チェックを受信すると、そのメディアストリームの ICE 処理の状態は Running から Completed に移行します。すべてのメディアストリームの ICE 処理の状態が Completed になると、ICE 処理全体の状態は Completed になります。

Lite 実装自体がメディアストリームの ICE 処理が失敗したと判断することはありません。むしろ、Full ピアがその判断を行い、後続のオファーで失敗したメディアストリームを削除または再開します。

8.2.2. Peer Is Lite (ピアは Lite)

オファー/アンサー交換が完了すると、両方のエージェントは自分の候補とピアの候補を調べます。各メディアストリームについて、各エージェントは自分の候補をそのメディアストリームのピアの候補とペアにします。2 つの候補は、同じコンポーネント用であり、同じトランスポートプロトコル（この仕様では UDP）を利用し、同じ IP アドレスファミリ（IPv4 または IPv6）のものである場合にペアになります。

• コンポーネントごとに 1 つのペアがある場合、そのペアは Valid リストに追加されます。メディアストリームのすべてのコンポーネントに 1 つのペアがあった場合、そのメディアストリームの ICE 処理の状態は Completed に設定されます。すべてのメディアストリームが Completed の場合、ICE 処理の状態は全体として Completed に設定されます。これは、IPv4 のみの実装の場合に常に当てはまります。

• コンポーネントごとに複数のペアがある場合：

  • エージェントはローカルポリシーに基づいてペアを選択しなければなりません (MUST)。このケースは IPv6 でのみ発生するため、エージェントは RFC 3484 [RFC3484] の手順に従って単一のペアを選択することが推奨されます (RECOMMENDED)。

  • エージェントは、各コンポーネントの選択されたペアを有効リストに追加します。セクション 11.1 で説明されているように、これによりメディアのフローを開始できます。ただし、両方のエージェントが異なるペアを選択した可能性があります（実際にはその可能性が高いです）。

  • これを調整するために、制御エージェントはセクション 9.1.3 で説明されているように更新されたオファーを送信しなければなりません (MUST)。これには remote-candidates 属性が含まれます。

  • エージェントは、オファーが送信されたときに ICE 処理の状態を更新してはなりません (MUST NOT)。この後続のオファーが完了すると、制御エージェントはすべてのメディアストリームの ICE 処理の状態を Completed に変更し、ICE 処理全体の状態を Completed に変更しなければなりません (MUST)。被制御エージェントの状態は、セクション 9.2.3 のロジックに基づいて設定されます。

8.3. Freeing Candidates (候補の解放)

8.3.1. Full Implementation Procedures (完全な実装の手順)

セクション 8 の手順では、そのストリームの処理が完了した後でも、エージェントが STUN リクエストをリッスンし続け、メディアストリームのトリガーチェックを生成し続けることが要求されます。このセクションのルールは、エージェントが ICE によって選択されなかった候補でのチェックの送信または受信を停止し、その後候補を解放するのが安全な時期について説明します。

ICE が SIP と共に使用され、オファーが複数の受信者にフォークされる場合、ICE は各アンサー側と並行して独立して進行し、すべて同じローカル候補を使用します。それらの候補を使用するメディアストリームのすべてのピアについて ICE 処理が Completed 状態に達したら、エージェントはさらに 3 秒待つべきであり (SHOULD)、その後、その候補でのチェックへの応答またはトリガーチェックの生成を停止してもよいです (MAY)。その時点で候補を解放してもよいです (MAY)。サーバー反射候補の解放は決して明示的ではありません。キープアライブがないことによって発生します。3 秒の遅延は、積極的指名が使用され、ICE が完了した後に選択されたペアがすぐに変更される可能性があるケースを処理します。

8.3.2. Lite Implementation Procedures (Lite 実装の手順)

Lite 実装は、それらの候補を使用するすべてのメディアストリームのすべてのピアについて ICE 処理が Completed 状態に達するとすぐに、ICE によって選択されなかった候補を解放してもよいです (MAY)。