9. Subsequent Offer/Answer Exchanges (後続のオファー/アンサー交換)

いずれのエージェントも、RFC 3264 [RFC3264] で許可されている任意の時点で後続のオファーを生成してもよいです (MAY)。セクション 8 のルールにより、ICE がデフォルトのペアとは異なる候補ペアを選択した場合、制御エージェントは ICE 処理の終了時に更新されたオファーを送信します。このセクションでは、後続のオファーとアンサーを構築するためのルールを定義します。

後続のオファーが拒否された場合、ICE 処理は後続のオファーが行われなかったかのように継続します。

9.1. Generating the Offer (オファーの生成)

9.1.1. Procedures for All Implementations (すべての実装の手順)

9.1.1.1. ICE Restarts (ICE 再起動)

エージェントは、既存のメディアストリームに対して ICE 処理を再起動してもよいです (MAY)。ICE 再起動は、その名前が示すように、ICE 処理の以前のすべての状態をフラッシュし、チェックを新たに開始させます。ICE 再起動とまったく新しいメディアセッションの唯一の違いは、再起動中に、以前に検証されたペアにメディアを送信し続けることができることです。

エージェントは、次の場合にメディアストリームの ICE を再起動しなければなりません (MUST)。

• オファーがメディアストリームのターゲットを変更する目的で生成されている場合。言い換えれば、エージェントが、ICE が使用されていなかった場合にメディアコンポーネントの宛先の新しい値になるような更新されたオファーを生成したい場合です。

• エージェントが実装レベルを変更している場合。これは通常、サードパーティの呼び出し制御のユースケースでのみ発生します。シグナリングを実行するエンティティはメディアを受信するエンティティではなく、セッションの途中でメディアのターゲットを異なる ICE 実装を持つ別のエンティティに変更しました。

これらのルールは、c 行の IP アドレスを 0.0.0.0 に設定すると ICE 再起動が発生することを意味します。その結果、ICE 実装はコールホールドにこのメカニズムを利用してはならず (MUST NOT)、代わりに [RFC3264] で説明されているように a=inactive と a=sendonly を使用しなければなりません (MUST)。

ICE を再起動するには、エージェントはオファー内のメディアストリームの ice-pwd と ice-ufrag の両方を変更しなければなりません (MUST)。1 つのオファーでセッションレベルの属性を使用し、後続のオファーで同じ ice-pwd または ice-ufrag をメディアレベルの属性として提供することは許容されることに注意してください。これはパスワードの変更ではなく、表現の変更にすぎず、ICE 再起動を引き起こしません。

エージェントは、このメディアストリームの初期オファーの場合と同じように、このメディアストリームの SDP の残りのフィールドを設定します（セクション 4.3 を参照）。その結果、候補のセットには、そのストリームの以前の候補の一部、なし、またはすべてが含まれる場合があり (MAY)、セクション 4.1.1 で説明されているように収集されたまったく新しい候補のセットが含まれる場合があります (MAY)。

9.1.1.2. Removing a Media Stream (メディアストリームの削除)

エージェントがポートをゼロに設定してメディアストリームを削除する場合、そのメディアストリームの候補属性を含めてはならず (MUST NOT)、そのメディアストリームに対してセクション 15 で定義されているその他の ICE 関連属性を含めるべきではありません (SHOULD NOT)。

9.1.1.3. Adding a Media Stream (メディアストリームの追加)

エージェントが新しいメディアストリームを追加したい場合、これがそのメディアストリームの初期オファーであるかのように、このメディアストリームの SDP のフィールドを設定します（セクション 4.3 を参照）。これにより、このメディアストリームの ICE 処理が開始されます。

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

このセクションでは、既存のメディアストリームをカバーする、完全な実装のための追加の手順について説明します。

ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用されたものと同じままでなければなりません (MUST)。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームの ICE を再起動しなければなりません (MUST)。

その他の動作は、そのメディアストリームの ICE 処理の状態によって異なります。

9.1.2.1. Existing Media Streams with ICE Running (ICE が実行中の既存のメディアストリーム)

エージェントが、以前に確立され、ICE チェックが Running 状態にあるメディアストリームを含む更新されたオファーを生成する場合、エージェントはここで定義された手順に従います。

エージェントは、そのメディアストリームに対して以前にシグナリングしたすべてのローカル候補の候補属性を含めなければなりません (MUST)。SDP でシグナリングされたその候補のプロパティ（優先順位、基盤、タイプ、および関連するトランスポートアドレス）は、同じままであるべきです (SHOULD)。その候補を根本的に識別する IP アドレス、ポート、およびトランスポートプロトコルは、同じままでなければなりません (MUST)（それらが変更された場合、それは新しい候補になります）。コンポーネント ID は同じままでなければなりません (MUST)。エージェントは、以前にオファーしなかったが、前回のオファー/アンサー交換以降に収集した追加の候補（ピア反射候補を含む）を含めてもよいです (MAY)。

エージェントはメディアのデフォルトの宛先を変更してもよいです (MAY)。初期オファーと同様に、オファーにはこのデフォルトの宛先と一致する候補属性のセットがなければなりません (MUST)。

9.1.2.2. Existing Media Streams with ICE Completed (ICE が完了した既存のメディアストリーム)

エージェントが、以前に確立され、ICE チェックが Completed 状態にあるメディアストリームを含む更新されたオファーを生成する場合、エージェントはここで定義された手順に従います。

メディアのデフォルトの宛先（つまり、そのメディアストリームに使用される m 行と c 行の IP アドレスとポートの値）は、各コンポーネントの有効リスト内の最も優先度の高い指名されたペアからのローカル候補でなければなりません (MUST)。これにより、メディアのデフォルトの宛先が、ICE がメディア用に選択した宛先と等しくなるように「修正」されます。

エージェントは、メディアストリームの各コンポーネントのデフォルトの宛先と一致する候補の候補属性を含めなければならず (MUST)、他の候補を含めてはなりません (MUST NOT)。

さらに、エージェントが制御側である場合、チェックリストが Completed 状態にある各メディアストリームの a=remote-candidates 属性を含めなければなりません (MUST)。この属性には、そのメディアストリームの各コンポーネントの有効リスト内の最も優先度の高い指名されたペアからのリモート候補が含まれます。これは、制御エージェントがペアを選択したが、更新されたオファーが被制御エージェントへの接続チェックよりも早く到着し、被制御エージェントがこれらのペアが選択されたことはおろか、有効であることさえ知らないという競合状態を回避するために必要です。この競合状態の詳細については、付録 B.6 を参照してください。

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

9.1.3.1. Existing Media Streams with ICE Running (ICE が実行中の既存のメディアストリーム)

このセクションでは、ICE が実行されている既存のストリームに対する Lite 実装の手順について説明します。

Lite 実装は、後続のオファーの a=candidate 属性に、各メディアストリームの各コンポーネントのすべての候補を含めなければなりません (MUST)。これらの候補は、セクション 4.2 で説明されている初期オファーの手順とまったく同じように形成されます。

Lite 実装は、後続のオファーに追加のホスト候補を追加してはなりません (MUST NOT)。エージェントが追加の候補をオファーする必要がある場合、ICE を再起動しなければなりません (MUST)。

ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用されたものと同じままでなければなりません (MUST)。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームの ICE を再起動しなければなりません (MUST)。

9.1.3.2. Existing Media Streams with ICE Completed (ICE が完了した既存のメディアストリーム)

メディアストリームの ICE が完了した場合、そのメディアストリームのデフォルトの宛先は、有効リスト内のそのコンポーネントの候補ペアのリモート候補に設定されなければなりません (MUST)。Lite 実装の場合、メディアストリームの各コンポーネントの有効リストには常に単一の候補ペアしかありません。さらに、エージェントは各デフォルトの宛先の候補属性を含めなければなりません (MUST)。

さらに、エージェントが制御側である場合（これは両方のエージェントが Lite である場合にのみ発生します）、エージェントは各メディアストリームの a=remote-candidates 属性を含めなければなりません (MUST)。この属性には、有効リスト内の候補ペアからのリモート候補が含まれます（各メディアストリームの各コンポーネントに 1 ペア）。

9.2. Receiving the Offer and Generating an Answer (オファーの受信とアンサーの生成)

9.2.1. Procedures for All Implementations (すべての実装の手順)

既存のセッション内で後続のオファーを受信する場合、エージェントは、以前のオファー/アンサー交換からの検証結果に関係なく、セクション 5.1 の検証手順を再適用しなければなりません (MUST)。実際、以前のオファー/アンサー交換の結果として ICE が使用されなかったが、後続の交換の結果として使用される可能性があります。

9.2.1.1. Detecting ICE Restart (ICE 再起動の検出)

オファーに、ピアからの以前の SDP と比較して a=ice-ufrag または a=ice-pwd 属性の変更が含まれていた場合、このメディアストリームの ICE が再起動していることを示します。すべてのメディアストリームが再起動している場合、ICE は全体的に再起動しています。

メディアストリームの ICE が再起動している場合：

• エージェントは、アンサー内の a=ice-ufrag および a=ice-pwd 属性を変更しなければなりません (MUST)。

• エージェントは、アンサー内で実装レベルを変更してもよいです (MAY)。

エージェントは、このメディアストリームへの初期アンサーの場合と同じように、このメディアストリームの SDP の残りのフィールドを設定します（セクション 4.3 を参照）。その結果、候補のセットには、そのストリームの以前の候補の一部、なし、またはすべてが含まれる場合があり (MAY)、セクション 4.1.1 で説明されているように収集されたまったく新しい候補のセットが含まれる場合があります (MAY)。

9.2.1.2. New Media Stream (新しいメディアストリーム)

オファーに新しいメディアストリームが含まれている場合、エージェントは、そのメディアストリームを含む初期オファーを受信したかのようにアンサーのフィールドを設定します（セクション 4.3 を参照）。これにより、このメディアストリームの ICE 処理が開始されます。

9.2.1.3. Removed Media Stream (削除されたメディアストリーム)

オファーにポートがゼロのメディアストリームが含まれている場合、エージェントはアンサーにそのメディアストリームの候補属性を含めてはならず (MUST NOT)、そのメディアストリームに対してセクション 15 で定義されているその他の ICE 関連属性を含めるべきではありません (SHOULD NOT)。

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

エージェントがオファーから ICE 再起動を検出しない限り、ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用されたものと同じままでなければなりません (MUST)。エージェントがこれらのいずれかを変更する必要がある場合、オファーを生成することによってそのメディアストリームの ICE を再起動しなければなりません (MUST)。アンサーで ICE を再起動することはできません。

その他の動作は、そのメディアストリームの ICE 処理の状態によって異なります。

9.2.2.1. Existing Media Streams with ICE Running and no remote-candidates (ICE が実行中で remote-candidates のない既存のメディアストリーム)

メディアストリームの ICE が実行中であり、そのメディアストリームのオファーに remote-candidates 属性がなかった場合、アンサーの構築ルールは、セクション 9.1.2.1 で説明されているオファー側のルールと同じです。

9.2.2.2. Existing Media Streams with ICE Completed and no remote-candidates (ICE が完了し remote-candidates のない既存のメディアストリーム)

メディアストリームの ICE が Completed であり、そのメディアストリームのオファーに remote-candidates 属性がなかった場合、アンサーの構築ルールは、セクション 9.1.2.2 で説明されているオファー側のルールと同じですが、アンサー側はアンサーに a=remote-candidates 属性を含めてはなりません (MUST NOT)。

9.2.2.3. Existing Media Streams and remote-candidates (既存のメディアストリームと remote-candidates)

被制御エージェントは、ピアがそのメディアストリームの ICE 処理を終了したときに、メディアストリームの a=remote-candidates 属性を含むオファーを受信します。この属性は、オファーの受信と、ICE によって選択される候補をアンサー側に伝える Binding レスポンスの受信との間の競合状態に対処するためにオファーに存在します。この競合状態の説明については、付録 B.6 を参照してください。その結果、この属性を持つオファーの処理は、レースの勝者に依存します。

エージェントは、次のようにしてメディアストリームの各コンポーネントの候補ペアを形成します。

• リモート候補を、そのコンポーネントのオファー側のデフォルトの宛先（たとえば、RTP の m 行と c 行の内容、および RTCP の a=rtcp 属性）に等しく設定する。

• ローカル候補を、オファー内の a=remote-candidates 属性の同じコンポーネントのトランスポートアドレスに等しく設定する。

その後、エージェントは、これらの各候補ペアが有効リストに存在するかどうかを確認します。特定のペアが有効リストにない場合、チェックはレースに「負け」ました。そのようなペアを「敗北ペア」と呼びます。

エージェントは、リモート候補が敗北ペアのリモート候補と等しいチェックリスト内のすべてのペアを見つけます。

• In-Progress のペアがなく、少なくとも 1 つが Failed の場合、ネットワークパーティションや深刻なパケット損失などのネットワーク障害が発生した可能性が最も高いです。エージェントは、remote-candidates 属性が存在しなかったかのようにこのメディアストリームのアンサーを生成し (SHOULD)、その後このストリームの ICE を再起動すべきです。

• 少なくとも 1 つのペアが In-Progress の場合、エージェントはそれらのチェックが完了するのを待つべきであり (SHOULD)、それぞれが完了するにつれて、敗北ペアがなくなるまでこのセクションの処理をやり直します。

敗北ペアがなくなると、エージェントはアンサーを生成できます。メディアのデフォルトの宛先を、オファーからの remote-candidates 属性の候補（それぞれが有効リスト内の候補ペアのローカル候補になります）に設定しなければなりません (MUST)。オファー内の remote-candidates 属性の各候補の候補属性をアンサーに含めなければなりません (MUST)。

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

受信したオファーにメディアストリームの remote-candidates 属性が含まれている場合、エージェントは次のようにしてメディアストリームの各コンポーネントの候補ペアを形成します。

• リモート候補を、そのコンポーネントのオファー側のデフォルトの宛先（たとえば、RTP の m 行と c 行の内容、および RTCP の a=rtcp 属性）に等しく設定する。

• ローカル候補を、オファー内の a=remote-candidates 属性の同じコンポーネントのトランスポートアドレスに等しく設定する。

その後、それらの候補をメディアストリームの Valid リストに配置します。そのメディアストリームの ICE 処理の状態は Completed に設定されます。

さらに、エージェントが自分が制御側であると信じていたが、オファーに remote-candidates 属性が含まれていた場合、両方のエージェントが自分が制御側であると信じています。この場合、両方がほぼ同時に更新されたオファーを送信したことになります。ただし、オファー/アンサー交換を運ぶシグナリングプロトコルは、このグレア状態を解決しているため、ピアがオファーを送信する前に自分のオファーが受信されることによって、一方のエージェントが常に「勝者」になります。勝者は被制御の役割を引き受けるため、敗者（このセクションで検討中のアンサー側）は役割を被制御に変更しなければなりません (MUST)。その結果、セクション 8.2.2 のルールに基づいて制御側であったため、エージェントが更新されたオファーを送信しようとしていた場合、もはやそうする必要はありません。

潜在的な役割の変更、Valid リストの変更、および状態の変更に加えて、アンサーの構築は、セクション 9.1.3 で説明されているオファーの構築とまったく同じように実行されます。

9.3. Updating the Check and Valid Lists (チェックリストと有効リストの更新)

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

9.3.1.1. ICE Restarts (ICE 再起動)

エージェントは、再起動の前に、メディアストリームの各コンポーネントの Valid リスト内の最も優先度の高い指名されたペア（以前の選択されたペアと呼ばれます）を記憶しなければなりません (MUST)。エージェントは、セクション 11.1 で説明されているように、これらのペアを使用してメディアを送信し続けます。これらの宛先が記録されると、エージェントは有効リストとチェックリストをフラッシュし、セクション 5.7 で説明されているようにチェックリストとその状態を再計算しなければなりません (MUST)。

9.3.1.2. New Media Stream (新しいメディアストリーム)

オファー/アンサー交換によって新しいメディアストリームが追加された場合、エージェントは、セクション 5.7 で説明されているように、それ用の新しいチェックリスト（およびもちろん開始するための空の Valid リスト）を作成しなければなりません (MUST)。

9.3.1.3. Removed Media Stream (削除されたメディアストリーム)

オファー/アンサー交換によってメディアストリームが削除された場合、またはアンサーがオファーされたメディアストリームを拒否した場合、エージェントはそのメディアストリームの Valid リストをフラッシュしなければなりません (MUST)。そのメディアストリームに対して進行中の STUN トランザクションを終了しなければなりません (MUST)。エージェントはそのメディアストリームのチェックリストを削除し、それに対する保留中の通常のチェックをキャンセルしなければなりません (MUST)。

9.3.1.4. ICE Continuing for Existing Media Stream (既存のメディアストリームに対する ICE の継続)

ICE が再起動しない限り、有効リストは更新されたオファー/アンサー交換の影響を受けません。

エージェントがそのメディアストリームに対して Running 状態にある場合、チェックリストが更新されます（状態が完了している場合、チェックリストは無関係です）。これを行うために、エージェントはセクション 5.7 で説明されている手順を使用してチェックリストを再計算します。新しいチェックリスト上のペアが以前のチェックリストにもあり、その状態が Waiting、In-Progress、Succeeded、または Failed であった場合、その状態はコピーされます。それ以外の場合、その状態は Frozen に設定されます。

チェックリストがいずれもアクティブでない場合（各チェックリストのペアが Frozen であることを意味します）、フルモードエージェントは、最初のメディアストリームのチェックリストの最初のペアを Waiting に設定し、次に同じコンポーネント ID と同じ基盤を持つそのチェックリスト内の他のすべてのペアの状態も Waiting に設定します。

次に、エージェントは、最も優先度の高いペアから順に各チェックリストを調べます。ペアの状態が Succeeded であり、コンポーネント ID が 1 の場合、同じ基盤を持ち、コンポーネント ID が 1 でない同じチェックリスト内のすべての Frozen ペアの状態が Waiting に設定されます。特定のチェックリストについて、そのメディアストリームの各コンポーネントのペアが Succeeded 状態にある場合、エージェントは、同じ基盤を持つ他のすべてのメディアストリーム（したがって異なるチェックリスト内）の最初のコンポーネントのすべての Frozen ペアの状態を Waiting に移動します。

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

メディアストリームの ICE が再起動している場合、エージェントはそのメディアストリーム用の新しい Valid リストを開始しなければなりません (MUST)。メディアストリームの各コンポーネントの以前の Valid リスト内のペア（以前の選択されたペアと呼ばれます）を記憶し、セクション 11.1 で説明されているようにそこにメディアを送信し続けなければなりません (MUST)。各メディアストリームの ICE 処理の状態は Running に変更しなければならず (MUST)、ICE 処理の状態は Running に変更しなければなりません (MUST)。