7. Performing Connectivity Checks (接続チェックの実行)

このセクションでは、接続チェックの実行方法について説明します。すべての ICE 実装は、古い [RFC3489] ではなく [RFC5389] に準拠することが要求されます。ただし、完全な実装はチェックの生成（STUN クライアントとして動作）と受信（STUN サーバーとして動作）の両方を行いますが、Lite 実装はチェックの受信のみを行い、したがって STUN サーバーとしてのみ動作します。

7.1. STUN Client Procedures (STUN クライアントの手順)

これらの手順は、通常チェックかトリガーチェックかに関わらず、エージェントが接続チェックを送信する方法を定義します。これらの手順は、完全な実装にのみ適用されます。

7.1.1. Creating Permissions for Relayed Candidates (リレー候補の許可の作成)

接続チェックがリレーされたローカル候補を使用して送信されている場合、クライアントは、以前に許可を作成していない場合、最初に許可を作成しなければなりません (MUST)。以前に TURN サーバーに対して、特定のリレー候補についてリモート候補の IP アドレスに対する許可を作成するように指示していた場合、以前に作成していることになります。許可を作成するために、エージェントは [RFC5766] で定義された手順に従います。許可は、リモート候補の IP アドレスに対して作成されなければなりません (MUST)。エージェントは ICE が完了するまで TURN チャネルの作成を延期することが推奨され (RECOMMENDED)、その場合、接続チェックの許可は通常 CreatePermission リクエストを使用して作成されます。一度確立されると、エージェントは ICE が終了するまで許可をアクティブに保たなければなりません (MUST)。

7.1.2. Sending the Request (リクエストの送信)

チェックは、ローカル候補からリモート候補へ Binding リクエストを送信することによって生成されます。[RFC5389] は、Binding リクエストの構築と生成方法を記述しています。接続チェックは STUN 短期認証情報メカニズムを利用しなければなりません (MUST)。接続チェックにおいて RFC 3489 との後方互換性のサポートを使用または想定してはなりません (MUST NOT)。接続チェックには FINGERPRINT メカニズムを使用しなければなりません (MUST)。

ICE は、PRIORITY、USE-CANDIDATE、ICE-CONTROLLED、および ICE-CONTROLLING を含むいくつかの新しい属性を定義することによって STUN を拡張します。これらの新しい属性はセクション 19.1 で正式に定義されており、その使用法は以下のサブセクションで説明されています。これらの STUN 拡張は、ICE に使用される接続チェックにのみ適用されます。

7.1.2.1. PRIORITY and USE-CANDIDATE (PRIORITY と USE-CANDIDATE)

エージェントは、Binding リクエストに PRIORITY 属性を含めなければなりません (MUST)。この属性は、このチェックの結果としてピア反射候補が学習された場合に（ピア反射候補の学習方法についてはセクション 7.1.3.2.1 を参照）、セクション 4.1.2 のアルゴリズムに基づいてそのピア反射候補に割り当てられる優先順位と等しく設定されなければなりません (MUST)。この優先順位の値は、タイプ優先度がピア反射候補タイプの値に設定されることを除いて、ペアのローカル候補の優先順位が計算されたのとまったく同様に計算されます。

制御エージェントは、Binding リクエストに USE-CANDIDATE 属性を含めることができます (MAY)。被制御エージェントは、Binding リクエストにそれを含めてはなりません (MUST NOT)。この属性は、制御エージェントがこのコンポーネントのチェックを停止し、このコンポーネントのチェックから生じた候補ペアを使用したいことを示します。セクション 8.1.1 は、いつそれを含めるかを決定するためのガイダンスを提供します。

7.1.2.2. ICE-CONTROLLED and ICE-CONTROLLING (ICE-CONTROLLED と ICE-CONTROLLING)

エージェントは、被制御ロールにある場合はリクエストに ICE-CONTROLLED 属性を含めなければならず (MUST)、制御ロールにある場合はリクエストに ICE-CONTROLLING 属性を含めなければなりません (MUST)。いずれかの属性の内容は、セクション 5.2 で決定されたタイブレーカーでなければなりません (MUST)。これらの属性はセクション 19.1 で完全に定義されています。

7.1.2.3. Forming Credentials (認証情報の形成)

接続チェックとして機能する Binding リクエストは、STUN 短期認証情報メカニズムを利用しなければなりません (MUST)。認証情報のユーザー名は、ピアによって提供されたユーザー名フラグメントと、リクエストを送信するエージェントのユーザー名フラグメントをコロン (":") で区切って連結することによって形成されます。パスワードは、ピアによって提供されたパスワードと等しくなります。たとえば、エージェント L がオファー側で、エージェント R がアンサー側である場合を考えます。エージェント L は候補に LFRAG というユーザー名フラグメントと LPASS というパスワードを含めました。エージェント R は RFRAG というユーザー名フラグメントと RPASS というパスワードを提供しました。L から R への接続チェックは、ユーザー名 RFRAG:LFRAG とパスワード RPASS を利用します。R から L への接続チェックは、ユーザー名 LFRAG:RFRAG とパスワード LPASS を利用します。レスポンスはリクエストと同じユーザー名とパスワードを利用します（レスポンスには USERNAME 属性が存在しないことに注意してください）。

7.1.2.4. DiffServ Treatment (DiffServ 処理)

エージェントがメディアパケットで Diffserv Codepoint マーキング [RFC2475] を使用している場合、接続チェックにも同じマーキングを適用すべきです (SHOULD)。

7.1.3. Processing the Response (レスポンスの処理)

Binding レスポンスが受信されると、[RFC5389] で定義されているように、トランザクション ID を使用して Binding リクエストに関連付けられ、それによって Binding リクエストが送信された候補ペアに結び付けられます。このセクションでは、この STUN の使用に固有の Binding レスポンスを処理するための追加の手順を定義します。

7.1.3.1. Failure Cases (失敗のケース)

STUN トランザクションが 487 (Role Conflict) エラーレスポンスを生成した場合、エージェントは Binding リクエストに ICE-CONTROLLED または ICE-CONTROLLING 属性を含めたかどうかを確認します。リクエストに ICE-CONTROLLED 属性が含まれていた場合、エージェントはまだ切り替えていない場合は制御ロールに切り替えなければなりません (MUST)。リクエストに ICE-CONTROLLING 属性が含まれていた場合、エージェントはまだ切り替えていない場合は被制御ロールに切り替えなければなりません (MUST)。切り替えが完了したら、エージェントは 487 を生成したチェックの候補ペアをトリガーチェックキューに追加しなければなりません (MUST)。そのペアの状態は Waiting に設定されます。トリガーチェックが送信されると、新しいロールを反映した ICE-CONTROLLING または ICE-CONTROLLED 属性が含まれます。ただし、タイブレーカー値は再選択してはならないことに注意してください (MUST NOT)。

ロールの変更は、ペアの優先順位が制御および被制御ロールの関数であるため、エージェントにペアの優先順位の再計算（セクション 5.7.2）を要求します。ロールの変更は、エージェントが指名されたペアの選択と ICE 終了時の更新されたオファーの生成に責任があるかどうかにも影響します。

エージェントは、接続チェックの ICMP エラーの受信をサポートしてもよいです (MAY)。STUN トランザクションが ICMP エラーを生成した場合、エージェントはペアの状態を Failed に設定します。STUN トランザクションが回復不可能な STUN エラーレスポンス（[RFC5389] で定義）を生成するか、タイムアウトした場合、エージェントはペアの状態を Failed に設定します。

エージェントは、レスポンスの送信元 IP アドレスとポートが Binding リクエストが送信された宛先 IP アドレスとポートと等しいこと、およびレスポンスの宛先 IP アドレスとポートが Binding リクエストが送信された送信元 IP アドレスとポートと一致することを確認しなければなりません (MUST)。言い換えれば、リクエストとレスポンスの送信元と宛先のトランスポートアドレスは対称です。それらが対称でない場合、エージェントはペアの状態を Failed に設定します。

7.1.3.2. Success Cases (成功のケース)

以下のすべてが真である場合、チェックは成功と見なされます。

• STUN トランザクションが成功レスポンスを生成した。
• レスポンスの送信元 IP アドレスとポートが、Binding リクエストが送信された宛先 IP アドレスとポートと等しい。
• レスポンスの宛先 IP アドレスとポートが、Binding リクエストが送信された送信元 IP アドレスとポートと一致する。

7.1.3.2.1. Discovering Peer Reflexive Candidates (ピア反射候補の発見)

エージェントは STUN レスポンスからのマッピングされたアドレスを確認します。トランスポートアドレスがエージェントが知っているローカル候補のいずれとも一致しない場合、マッピングされたアドレスは新しい候補、つまりピア反射候補を表します。他の候補と同様に、タイプ、ベース、優先順位、および基盤を持ちます。これらは次のように計算されます。

• そのタイプはピア反射に等しい。
• そのベースは、STUN チェックが送信された候補ペアのローカル候補に等しく設定される。
• その優先順位は、Binding リクエストの PRIORITY 属性の値に等しく設定される。
• その基盤はセクション 4.1.1.3 で説明されているように選択される。

このピア反射候補は、その後メディアストリームのローカル候補のリストに追加されます。そのユーザー名フラグメントとパスワードは、そのメディアストリームの他のすべてのローカル候補と同じです。

ただし、ピア反射候補は他のリモート候補とペアになりません。これは必要ありません。セクション 7.1.3.2.2 の手順に基づいて、有効なペアがすぐに生成されます。エージェントが生成される有効なペアのリモート候補以外の他のリモート候補とピア反射候補をペアにしたい場合、エージェントはピア反射候補を含む更新されたオファーを生成してもよいです (MAY)。これにより、他のすべてのリモート候補とペアになります。

7.1.3.2.2. Constructing a Valid Pair (有効なペアの構築)

エージェントは、ローカル候補がレスポンスのマッピングされたアドレスに等しく、リモート候補がリクエストが送信された宛先アドレスに等しい候補ペアを構築します。これは STUN 接続チェックによって検証されているため、有効なペアと呼ばれます。有効なペアは、チェックを生成したペアと等しい場合、チェックリスト内の別のペアと等しい場合、または現在どのチェックリストにもないペアである場合があります。ペアがチェックを生成したペアと等しいか、現在チェックリストにある場合、エージェントが各メディアストリームに対して維持する VALID LIST にも追加されます。このリストは ICE 処理の開始時には空であり、チェックが実行されるにつれて埋められ、有効な候補ペアが得られます。

ペアがどのチェックリストにもないことは非常に一般的です。チェックリストには、ローカル候補がサーバー反射ではないペアがあることを思い出してください。これらのペアは、ローカル候補がサーバー反射候補のベースに変換され、冗長であればプルーニングされました。STUN チェックへのレスポンスが到着すると、2 つの間に NAT がある場合、マッピングされたアドレスは反射的になります。その場合、有効なペアは、チェックリスト内のどのペアとも一致しないローカル候補を持ちます。

ペアがどのチェックリストにもない場合、エージェントはセクション 5.7 のアルゴリズムを使用して、各候補の優先順位に基づいてペアの優先順位を計算します。ローカル候補の優先順位は、そのタイプによって異なります。ピア反射でない場合は、SDP でその候補に対してシグナリングされた優先順位と等しくなります。ピア反射である場合は、エージェントが完了したばかりの Binding リクエストに配置した PRIORITY 属性と等しくなります。リモート候補の優先順位は、ピアの SDP から取得されます。候補がそこに表示されない場合、チェックは新しいリモート候補へのトリガーチェックであったに違いありません。その場合、優先順位は、完了したばかりのチェックをトリガーした Binding リクエストの PRIORITY 属性の値として取得されます。その後、ペアは VALID LIST に追加されます。

7.1.3.2.3. Updating Pair States (ペアの状態の更新)

エージェントは、チェックを生成したペアの状態を Succeeded に設定します。チェックを生成したペアは、レスポンスの結果としてセクション 7.1.3.2.2 で構築された有効なペアとは異なる場合があることに注意してください。このチェックの成功により、他のチェックの状態も変更される可能性があります。エージェントは次の 2 つのステップを実行しなければなりません (MUST)。

1. エージェントは、同じメディアストリームと同じ基盤の他のすべての Frozen ペアの状態を Waiting に変更します。通常、常にではありませんが、これらの他のペアは異なるコンポーネント ID を持ちます。

2. このメディアストリームのすべてのコンポーネントに対して有効なリストにペアがある場合（SDP でシグナリングされたコンポーネントの数がオファー側とアンサー側で異なる場合、これは実際に使用されているコンポーネントの数です）、このチェックの成功により、他のメディアストリームのチェックが解凍される可能性があります。このステップは、考慮中の有効なリストがすべてのコンポーネントのペアを初めて持つときだけでなく、チェックが成功してその有効なリストにさらに別のペアを追加するたびに実行されることに注意してください。エージェントは、他の各メディアストリームのチェックリストを順番に調べます。

   • チェックリストがアクティブな場合、エージェントはそのチェックリスト内の基盤が考慮中の有効なリスト内のペアと一致するすべての Frozen ペアの状態を Waiting に変更します。

   • チェックリストが凍結されており、チェックリスト内に基盤が考慮中の有効なリスト内のペアと一致するペアが少なくとも 1 つある場合、チェックリスト内の基盤が考慮中の有効なリスト内のペアと一致するすべてのペアの状態が Waiting に設定されます。これにより、チェックリストがアクティブになり、セクション 5.8 で説明されているように、通常のチェックが開始されます。

   • チェックリストが凍結されており、チェックリスト内に基盤が考慮中の有効なリスト内のペアと一致するペアがない場合、エージェントは

     • 同じ基盤を持つすべてのペアをグループ化し、

     • 各グループについて、最も低いコンポーネント ID を持つペアの状態を Waiting に設定します。そのようなペアが複数ある場合は、最も高い優先順位を持つペアが使用されます。

7.1.3.2.4. Updating the Nominated Flag (指名フラグの更新)

エージェントが制御エージェントであり、Binding リクエストに USE-CANDIDATE 属性を含めていた場合、そのチェックから生成された有効なペアは、指名フラグが true に設定されます。このフラグは、指名フラグが設定されているものの中で最も優先順位が高い場合、この有効なペアをメディアに使用する必要があることを示します。これにより、このメディアストリームまたはすべてのメディアストリームの ICE 処理が終了する場合があります。セクション 8 を参照してください。

エージェントが被制御エージェントである場合、レスポンスは、それ自体が USE-CANDIDATE 属性を持っていたリクエストに応答して送信されたトリガーチェックの結果である可能性があります。このケースはセクション 7.2.1.5 で説明されており、元のリクエストから学習されたペアの指名フラグを設定する結果となる可能性があります。

7.1.3.3. Check List and Timer State Updates (チェックリストとタイマー状態の更新)

チェックが成功したか失敗したかに関わらず、トランザクションの完了にはチェックリストとタイマー状態の更新が必要になる場合があります。

チェックリスト内のすべてのペアが現在 Failed または Succeeded 状態にある場合：

• メディアストリームの各コンポーネントに対して有効なリストにペアがない場合、チェックリストの状態は Failed に設定されます。

• 各凍結チェックリストについて、エージェントは

  • 同じ基盤を持つすべてのペアをグループ化し、

  • 各グループについて、最も低いコンポーネント ID を持つペアの状態を Waiting に設定します。そのようなペアが複数ある場合は、最も高い優先順位を持つペアが使用されます。

チェックリスト内のどのペアも Waiting または Frozen 状態にない場合、チェックリストはもはやアクティブとは見なされず、セクション 5.8 で説明されている通常のチェックのタイマーの計算における N の値にはカウントされません。

7.2. STUN Server Procedures (STUN サーバーの手順)

エージェントは、最新のオファーまたはアンサーに含めた各候補のベースで Binding リクエストを受信する準備ができていなければなりません (MUST)。この要件は、ピアが Lite 実装である場合でも当てはまります。

エージェントは、リクエストを認証し、メッセージ整合性チェックを実行するために、短期認証情報を使用しなければなりません (MUST)。エージェントは、ユーザー名がコロンで区切られた 2 つの値で構成され、最初の値が進行中のセッションのオファーまたはアンサーでエージェントによって生成されたユーザー名フラグメントと等しい場合、ユーザー名を有効と見なさなければなりません (MUST)。オファー側は、ピアからアンサーを受信する前に Binding リクエストを受信する可能性があり（実際には非常に高い）、その場合、エージェントは直ちにレスポンスを生成しなければなりません (MUST)（セクション 7.2.1.2 で説明されているマッピングされたアドレスの計算を含む）。エージェントは、この時点でレスポンスを生成するための十分な情報を持っています。ピアからのパスワードは必要ありません。アンサーが受信されると、完全な実装のために必要な残りのステップ、つまり 7.2.1.3、7.2.1.4、および 7.2.1.5 を進めなければなりません (MUST)。アンサーの前に複数の STUN リクエストが受信される場合、これにより複数のペアがトリガーチェックキューにキューイングされる可能性があります。

エージェントは ALTERNATE-SERVER メカニズムを利用してはならず (MUST NOT)、RFC 3489 への後方互換性メカニズムをサポートしてはなりません (MUST NOT)。FINGERPRINT メカニズムを利用しなければなりません (MUST)。

エージェントがメディアパケットで Diffserv Codepoint マーキング [RFC2475] を使用している場合、Binding リクエストへのレスポンスにも同じマーキングを適用すべきです (SHOULD)。エンドポイントがメディアパケットに適用している可能性のあるレイヤー 2 マーキングにも同じことが当てはまります。

7.2.1. Additional Procedures for Full Implementations (完全な実装のための追加手順)

このサブセクションでは、完全な実装に適用可能な追加のサーバー手順を定義します。

7.2.1.1. Detecting and Repairing Role Conflicts (ロール競合の検出と修復)

通常、セクション 5.2 のロール選択のルールにより、各エージェントは異なるロール（1 つは制御、もう 1 つは被制御）を選択します。ただし、通常はサードパーティの呼び出し制御を利用する異常な呼び出しフローでは、両方のエージェントが同じロールを選択する可能性があります。このセクションでは、このケースをチェックして修復するための手順について説明します。

エージェントは、Binding リクエストの ICE-CONTROLLING または ICE-CONTROLLED 属性を調べなければなりません (MUST)。以下の手順に従わなければなりません (MUST)。

• リクエストに ICE-CONTROLLING も ICE-CONTROLLED も存在しない場合、ピアエージェントはこの仕様の以前のバージョンを実装している可能性があります。競合があるかもしれませんが、検出できません。

• エージェントが制御ロールにあり、リクエストに ICE-CONTROLLING 属性が存在する場合：

  • エージェントのタイブレーカーが ICE-CONTROLLING 属性の内容以上である場合、エージェントは Binding エラーレスポンスを生成し、値 487 (Role Conflict) の ERROR-CODE 属性を含めますが、ロールは保持します。

  • エージェントのタイブレーカーが ICE-CONTROLLING 属性の内容未満である場合、エージェントは被制御ロールに切り替えます。

• エージェントが被制御ロールにあり、リクエストに ICE-CONTROLLED 属性が存在する場合：

  • エージェントのタイブレーカーが ICE-CONTROLLED 属性の内容以上である場合、エージェントは制御ロールに切り替えます。

  • エージェントのタイブレーカーが ICE-CONTROLLED 属性の内容未満である場合、エージェントは Binding エラーレスポンスを生成し、値 487 (Role Conflict) の ERROR-CODE 属性を含めますが、ロールは保持します。

• エージェントが被制御ロールにあり、リクエストに ICE-CONTROLLING 属性が存在した場合、またはエージェントが制御ロールにあり、リクエストに ICE-CONTROLLED 属性が存在した場合、競合はありません。

ロールの変更は、ペアの優先順位が制御および被制御ロールの関数であるため、エージェントにペアの優先順位の再計算（セクション 5.7.2）を要求します。ロールの変更は、エージェントが指名されたペアの選択と ICE 終了時の更新されたオファーの生成に責任があるかどうかにも影響します。

セクション 7.2.1 の残りのセクションは、エージェントがロールを変更した場合でも、サーバーが Binding リクエストに対して成功レスポンスを生成した場合に従います。

7.2.1.2. Computing Mapped Address (マッピングされたアドレスの計算)

リレー候補で受信されるリクエストの場合、STUN 処理（つまり、XOR-MAPPED-ADDRESS 属性の生成）に使用される送信元トランスポートアドレスは、TURN サーバーによって見られるトランスポートアドレスです。Binding リクエストが Data Indication を介して配信された場合、その送信元トランスポートアドレスは Data Indication メッセージの XOR-PEER-ADDRESS 属性に存在します。Binding リクエストが ChannelData メッセージを介して配信された場合、送信元トランスポートアドレスはチャネルにバインドされたものです。

7.2.1.3. Learning Peer Reflexive Candidates (ピア反射候補の学習)

リクエストの送信元トランスポートアドレスが既存のリモート候補のいずれとも一致しない場合、それは新しいピア反射リモート候補を表します。この候補は次のように構築されます。

• 候補の優先順位は、リクエストの PRIORITY 属性に設定されます。
• 候補のタイプはピア反射に設定されます。
• 候補の基盤は、他のすべてのリモート候補の基盤とは異なる任意の値に設定されます。後続のオファー/アンサー交換のいずれかが SDP にこのピア反射候補を含んでいる場合、それは候補の実際の基盤をシグナリングします。
• この候補のコンポーネント ID は、リクエストが送信されたローカル候補のコンポーネント ID に設定されます。

この候補はリモート候補のリストに追加されます。ただし、エージェントはこの候補をどのローカル候補ともペアにしません。

7.2.1.4. Triggered Checks (トリガーチェック)

次に、エージェントは、ローカル候補が STUN リクエストを受信したトランスポートアドレスに等しく、リモート候補がリクエストの送信元の送信元トランスポートアドレス（学習されたばかりのピア反射リモート候補である可能性があります）に等しいペアを構築します。ローカル候補は、ホスト候補（リクエストがリレーを介して受信されなかった場合）またはリレー候補（リレーを介して受信された場合）のいずれかになります。ローカル候補は決してサーバー反射候補にはなり得ません。エージェントは両方の候補を知っているので、それらの優先順位を取得し、候補ペアの優先順位を計算できます。その後、このペアはチェックリストで検索されます。いくつかの結果のいずれかになる可能性があります。

• ペアがすでにチェックリストにある場合：

  • そのペアの状態が Waiting または Frozen の場合、まだ存在しない場合は、そのペアのチェックがトリガーチェックキューに追加されます。

  • そのペアの状態が In-Progress の場合、エージェントは進行中のトランザクションをキャンセルします。キャンセルとは、エージェントがリクエストを再送信せず、レスポンスがないことを失敗として扱わず、レスポンスを得るためにトランザクションタイムアウトの間待つことを意味します。さらに、エージェントは、ペアをトリガーチェックキューに追加することにより、そのペアの新しい接続チェック（新しい STUN Binding リクエストトランザクションを表す）を作成しなければなりません (MUST)。その後、ペアの状態は Waiting に変更されます。

  • そのペアの状態が Failed の場合、Waiting に変更され、エージェントはペアをトリガーチェックキューに追加することにより、そのペアの新しい接続チェック（新しい STUN Binding リクエストトランザクションを表す）を作成しなければなりません (MUST)。

  • そのペアの状態が Succeeded の場合、それ以上何もしません。

  これらのステップは、両方のエージェントが NAT の背後にある場合に ICE の迅速な完了を促進するために行われます。

• ペアがまだチェックリストにない場合：

  • ペアは優先順位に基づいてチェックリストに挿入されます。

  • その状態は Waiting に設定されます。

  • ペアはトリガーチェックキューに追加されます。

トリガーチェックを送信する場合、セクション 7.1.2 で説明されているように構築および処理されます。これらの手順では、エージェントがピアのトランスポートアドレス、ユーザー名フラグメント、およびパスワードを知っている必要があります。リモート候補のユーザー名フラグメントは、受信したばかりの Binding リクエストの USERNAME のコロンの後の部分と等しくなります。そのユーザー名フラグメントを使用して、エージェントはピアから受信した SDP メッセージ（フォークの場合は複数ある可能性があります）を確認し、このユーザー名フラグメントを見つけることができます。その後、対応するパスワードが選択されます。

7.2.1.5. Updating the Nominated Flag (指名フラグの更新)

エージェントが受信した Binding リクエストに USE-CANDIDATE 属性が設定されており、エージェントが被制御ロールにある場合、エージェントはセクション 7.2.1.4 で計算されたペアの状態を確認します。

• このペアの状態が Succeeded の場合、このペアによって生成されたチェックが成功レスポンスを生成したことを意味します。これにより、その成功レスポンスが受信されたときにエージェントは有効なペアを構築したはずです（セクション 7.1.3.2.2 を参照）。エージェントは現在、有効なペアの指名フラグを true に設定します。これにより、このメディアストリームの ICE 処理が終了する場合があります。セクション 8 を参照してください。

• このペアの状態が In-Progress の場合、そのチェックが成功結果を生成すると、レスポンスが到着したときに、結果として得られる有効なペアの指名フラグが設定されます。それが到着すると、これによりこのメディアストリームの ICE 処理が終了する場合があります。セクション 8 を参照してください。

7.2.2. Additional Procedures for Lite Implementations (Lite 実装のための追加手順)

受信したばかりのチェックに USE-CANDIDATE 属性が含まれていた場合、エージェントは、ローカル候補がリクエストを受信したトランスポートアドレスに等しく、リモート候補が受信したリクエストの送信元トランスポートアドレスに等しい候補ペアを構築します。この候補ペアには任意の優先順位が割り当てられ、有効リストと呼ばれる有効な候補のリストに配置されます。エージェントはそのペアの指名フラグを true に設定します。有効リストに各コンポーネントの候補ペアが含まれている場合、メディアストリームの ICE 処理は完了したと見なされます。