5. Receiving the Initial Offer (初期オファーの受信)
エージェントが初期オファーを受信すると、オファーラーが ICE をサポートしているかどうかを確認し、自身の役割を決定し、候補を収集し、優先順位を付け、デフォルトの候補を選択し、アンサーをエンコードして送信し、フル実装の場合はチェックリストを作成して接続チェックを開始します。
5.1. Verifying ICE Support (ICE サポートの検証)
受信した SDP 内の各メディアストリームについて、そのメディアストリームの各コンポーネントのデフォルト宛先が candidate 属性に現れる場合、エージェントは本仕様で定義されている ICE 手順を続行します。たとえば、RTP の場合、c 行と m 行の IP アドレスとポートがそれぞれ candidate 属性に現れ、rtcp 属性の値が candidate 属性に現れます。
この条件が満たされない場合、エージェントは、以下の例外を除き、本仕様の残りの部分で説明されている ICE メカニズムを使用せずに、通常の RFC 3264 手順に基づいて SDP を処理しなければなりません (MUST)。
-
エージェントは、すべてのエージェントのキープアライブ手順を説明するセクション 10 のルールに従わなければなりません (MUST)。
-
a=candidate 属性はあったが、メディアストリームのデフォルト宛先と一致するものがなかったためにエージェントが ICE を続行しない場合、エージェントはアンサーに a=ice-mismatch 属性を含めなければなりません (MUST)。
-
デフォルトの候補が TURN サーバーを通じて学習されたリレー候補であった場合、エージェントは、受信したばかりの SDP でピアから学習した IP アドレスに対して TURN サーバーにパーミッションを作成しなければなりません (MUST)。これが行われないと、ピアからのメディアストリーム内の初期パケットが失われる可能性があります。
5.2. Determining Role (役割の決定)
各セッションについて、各エージェントは役割を担います。役割には、制御 (Controlling) と被制御 (Controlled) の 2 つがあります。制御エージェントは、通信に使用される最終的な候補ペアの選択に責任を持ちます。フルエージェントの場合、これは、各メディアストリームに対して ICE で使用できる候補ペアを指名し、必要に応じて ICE の選択に基づいて更新されたオファーを生成することを意味します。ライト実装の場合、制御エージェントであるということは、オファーとアンサーにあるものに基づいて候補ペアを選択し（IPv4 の場合、ペアは常に 1 つだけです）、必要に応じてその選択を反映した更新されたオファーを生成することを意味します（IPv4 のみのホストの場合は必要ありません）。被制御エージェントは、各メディアストリームに使用する候補ペアを指示され、この情報を通知するための更新されたオファーを生成しません。以下のセクションでは、制御ノードと被制御ノードが従う実際の手順について詳しく説明します。
役割と動作への影響を決定するためのルールは次のとおりです。
-
両方のエージェントがフル実装： ICE 処理を開始したオファーを生成したエージェントは制御の役割を担わなければならず (MUST)、もう一方は被制御の役割を担わなければなりません (MUST)。両方のエージェントは、チェックリストを作成し、ICE ステートマシンを実行し、接続チェックを生成します。制御エージェントは、ICE によって選択されるペアを指名するためにセクション 8.1 のロジックを実行し、その後、両方のエージェントはセクション 8.1.2 で説明されているように ICE を終了します。付録 B.11 で説明されている通常とは異なるケースでは、両方のエージェントが誤って自分が被制御または制御であると信じる可能性があります。これを解決するために、各エージェントは、タイブレーカー (tie-breaker) と呼ばれる、0 から (2**64) - 1 の間（つまり、64 ビットの正の整数）で均一に分布した乱数を選択しなければなりません (MUST)。この数値は、セクション 7.1.2.2 で説明されているように、このケースを検出して修復するために接続チェックで使用されます。
-
1 つのエージェントがフル、1 つがライト： フルエージェントは制御の役割を担わなければならず (MUST)、ライトエージェントは被制御の役割を担わなければなりません (MUST)。フルエージェントは、チェックリストを作成し、ICE ステートマシンを実行し、接続チェックを生成します。そのエージェントは、ICE によって選択されるペアを指名するためにセクション 8.1 のロジックを実行し、セクション 8.1.2 のロジックを使用して ICE を終了します。ライト実装は、単に接続チェックをリッスンし、それらを受信して応答し、セクション 8.2 で説明されているように ICE を終了します。ライト実装の場合、各メディアストリームの ICE 処理の状態は Running (実行中) と見なされ、ICE 全体の状態は Running です。
-
両方がライト： ICE 処理を開始したオファーを生成したエージェントは制御の役割を担わなければならず (MUST)、もう一方は被制御の役割を担わなければなりません (MUST)。この場合、接続チェックは送信されません。むしろ、オファー/アンサー交換が完了すると、各エージェントは接続チェックなしでセクション 8 で説明されている処理を実行します。両方のエージェントが自分が被制御または制御であると信じる可能性があります。後者の場合、競合は、オファー/アンサー交換を伝送するシグナリングプロトコルのグレア (glare) 検出機能によって解決されます。各メディアストリームの ICE 処理の状態は Running と見なされ、ICE 全体の状態は Running です。
セッションの役割が決定されると、ICE が再開されない限り、それらは持続します。ICE の再開（セクション 9.1）により、役割とタイブレーカーが新たに選択されます。
5.3. Gathering Candidates (候補の収集)
アンサーラーでの候補の収集プロセスは、フル実装の場合はセクション 4.1.1、ライト実装の場合はセクション 4.2 で説明されているオファーラーのプロセスと同じです。このプロセスは、ユーザーに警告する前に、オファーを受信したらすぐに開始することが推奨されます (RECOMMENDED)。このような収集は、エージェントの起動時に開始される場合があります (MAY)。
5.4. Prioritizing Candidates (候補の優先順位付け)
アンサーラーでの候補の優先順位付けプロセスは、フル実装の場合はセクション 4.1.2、ライト実装の場合はセクション 4.2 で説明されているオファーラーが従うプロセスと同じです。
5.5. Choosing Default Candidates (デフォルト候補の選択)
アンサーラーでのデフォルト候補の選択プロセスは、フル実装の場合はセクション 4.1.4、ライト実装の場合はセクション 4.2 で説明されているオファーラーが従うプロセスと同じです。
5.6. Encoding the SDP (SDP のエンコード)
アンサーラーでの SDP のエンコードプロセスは、セクション 4.3 で説明されているように、フル実装とライト実装の両方についてオファーラーが従うプロセスと同じです。
5.7. Forming the Check Lists (チェックリストの作成)
チェックリストの作成は、フル実装によってのみ行われます。ライト実装は、このセクションで定義されている手順をスキップしなければなりません (MUST)。
オファー/アンサー交換の結果として生じる使用中のメディアストリームごとに 1 つのチェックリストがあります。メディアストリームのチェックリストを作成するために、エージェントは候補ペアを作成し、候補ペアの優先順位を計算し、優先順位順にペアを並べ替え、それらをプルーニングし、それらの状態を設定します。これらの手順については、このセクションで説明します。
5.7.1. Forming Candidate Pairs (候補ペアの作成)
まず、エージェントは、メディアストリームの各候補（ローカル候補 LOCAL CANDIDATES と呼ばれる）を取得し、そのメディアストリームについてピアから受信した候補（リモート候補 REMOTE CANDIDATES と呼ばれる）とペアにします。セクション 18.5.2 で説明されている攻撃を防ぐために、エージェントは、オファーまたはアンサーで受け入れる候補の数を制限する場合があります (MAY)。ローカル候補は、2 つの候補が同じコンポーネント ID を持ち、同じ IP アドレスバージョンを持っている場合にのみ、リモート候補とペアになります。一部のローカル候補がリモート候補とペアにならず、一部のリモート候補がローカル候補とペアにならない可能性があります。これは、一方のエージェントがメディアストリームのすべてのコンポーネントの候補を含めていない場合に発生する可能性があります。これが発生した場合、そのメディアストリームのコンポーネントの数は事実上減少し、メディアストリームのすべてのコンポーネントにわたって各エージェントによって提供される最大コンポーネント ID の両方のエージェント間の最小値に等しいと見なされます。
RTP の場合、これは、一方のエージェントが RTCP の候補を提供し、もう一方が提供しない場合に発生します。別の例として、オファーラーは RTP と RTCP を同じポートで多重化し、SDP 属性 [RFC5761] を通じて SDP でそれができることを通知できます。ただし、オファーラーはアンサーラーがそのような多重化を実行できるかどうかわからないため、オファーラーは RTP と RTCP の候補を別々のポートに含め、オファーにはメディアストリームごとに 2 つのコンポーネントが含まれるようにします。アンサーラーがそのような多重化を実行できる場合、アンサーラーは各候補に対して単一のコンポーネント（結合された RTP/RTCP mux 用）のみを含めます。ICE は、この候補に対してコンポーネントが 1 つしかないかのように動作することになります。
ローカル候補とリモート候補の両方が特定のコンポーネントのデフォルト候補である候補ペアは、当然のことながら、そのコンポーネントのデフォルト候補ペアと呼ばれます。これは、両方のエージェントが ICE を認識していなかった場合にメディアを送信するために使用されるペアです。
理解を助けるために、図 6 は、候補と候補ペアの主なプロパティを示すことに加えて、いくつかの重要な概念（トランスポートアドレス、候補、候補ペア、およびチェックリスト）間の関係を示しています。
+------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation |
| |+----+ +----+ +----+ | +ComponentiD |
| | Transport | +RelatedAddr |
| | Addr | |
| +---------------------+ +Base |
| Candidate |
+------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
.| |
| Local Remote |
| +----+ +----+ +default? |
| |Cand| |Cand| +valid? |
| +----+ +----+ +nominated?|
| +State |
| |
| |
| Candidate Pair |
+-------------------------------+
* *
* ************
* *
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
+------------------+
| Candidate Pair |
+------------------+
Check
List
図 6: チェックリストの概念図
5.7.2. Computing Pair Priority and Ordering Pairs (ペアの優先順位の計算とペアの順序付け)
ペアが形成されると、候補ペアの優先順位が計算されます。G を制御エージェントによって提供された候補の優先順位とします。D を被制御エージェントによって提供された候補の優先順位とします。ペアの優先順位は次のように計算されます。
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
ここで、G>D?1:0 は、G が D より大きい場合は値が 1、それ以外の場合は 0 になる式です。優先順位が割り当てられると、エージェントは候補ペアを優先順位の降順で並べ替えます。2 つのペアが同じ優先順位を持つ場合、それらの間の順序は任意です。
5.7.3. Pruning the Pairs (ペアのプルーニング)
この並べ替えられた候補ペアのリストは、実行される接続チェックのシーケンスを決定するために使用されます。各チェックには、ローカル候補からリモート候補へのリクエストの送信が含まれます。エージェントは反射候補から直接リクエストを送信することはできず、そのベースからのみ送信できるため、エージェントは次に候補ペアの並べ替えられたリストを調べます。ローカル候補がサーバー反射である各ペアについて、サーバー反射候補はそのベースに置き換えられなければなりません (MUST)。これが行われると、エージェントはリストをプルーニングしなければなりません (MUST)。これは、ローカル候補とリモート候補が優先順位リストの上位にあるペアのローカル候補とリモート候補と同一である場合に、ペアを削除することによって行われます。結果は、そのメディアストリームのチェックリストと呼ばれる、順序付けられた候補ペアのシーケンスです。
さらに、セクション 18.5.2 で説明されている攻撃を制限するために、エージェントは、エージェントがすべてのチェックリストにわたって実行する接続チェックの総数を特定の値に制限しなければならず (MUST)、この値は構成可能でなければなりません (MUST)。デフォルトは 100 が推奨されます (RECOMMENDED)。この制限は、100 未満になるまで優先順位の低い候補ペアを破棄することによって強制されます。実際の展開構成で見られる可能性のあるもっともらしいチェックの最大数に設定して、可能な場合はより低い値を利用することが推奨されます (RECOMMENDED)。構成の要件は、展開後に問題があることが判明した場合に、現場でこの値を修正するためのツールを提供することを目的としています。
5.7.4. Computing States (状態の計算)
チェックリスト内の各候補ペアには、ファンデーションと状態があります。ファンデーションは、ペア内のローカル候補とリモート候補のファンデーションの組み合わせです。各メディアストリームのチェックリストが計算されると、状態が割り当てられます。状態が持つ可能性のある値は 5 つあります。
-
Waiting (待機): このペアに対してチェックは実行されておらず、チェックリストで優先順位が最も高い Waiting ペアになるとすぐに実行できます。
-
In-Progress (進行中): このペアに対してチェックが送信されましたが、トランザクションは進行中です。
-
Succeeded (成功): このペアのチェックはすでに完了し、成功した結果が得られました。
-
Failed (失敗): このペアのチェックはすでに完了し、失敗しました。応答が生成されなかったか、回復不可能な失敗応答が生成されました。
-
Frozen (凍結): このペアのチェックは実行されておらず、他のチェックが成功してこのペアが解凍され、Waiting 状態に移行できるようになるまで実行できません。
ICE が実行されると、ペアは図 7 に示すように状態間を移動します。
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
|unfreeze
|
V
+-----------+ +-----------+
| | | |
| | perform | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
failure // |success
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+
図 7: ペア状態 FSM
チェックリスト内の各ペアの初期状態は、次の手順を実行することによって計算されます。
-
エージェントは、各チェックリスト内のすべてのペアを Frozen 状態に設定します。
-
エージェントは、最初のメディアストリーム（SDP オファーおよびアンサーの最初の m 行で記述されている場合、メディアストリームは最初のメディアストリームです）のチェックリストを調べます。そのメディアストリームについて：
- 同じファンデーションを持つすべてのペアについて、コンポーネント ID が最も低いペアの状態を Waiting に設定します。そのようなペアが複数ある場合は、優先順位が最も高いペアが使用されます。
チェックリストの 1 つには Waiting 状態のペアがいくつかあり、他のチェックリストにはすべてのペアが Frozen 状態になります。少なくとも 1 つのペアが Waiting であるチェックリストはアクティブチェックリスト (active check list) と呼ばれ、すべてのペアが Frozen であるチェックリストは凍結チェックリスト (frozen check list) と呼ばれます。
チェックリスト自体は状態に関連付けられており、そのメディアストリームの ICE チェックの状態をキャプチャします。3 つの状態があります。
-
Running (実行中): この状態では、このメディアストリームに対して ICE チェックがまだ進行中です。
-
Completed (完了): この状態では、ICE チェックにより、メディアストリームの各コンポーネントに対して指名されたペアが生成されています。その結果、ICE は成功し、メディアを送信できます。
-
Failed (失敗): この状態では、このメディアストリームの ICE チェックは正常に完了していません。
オファー/アンサー交換の結果としてチェックリストが最初に構築されると、Running 状態になります。
すべてのメディアストリームにわたる ICE 処理にも、それに関連付けられた状態があります。この状態は、ICE 処理が進行中の間は Running に等しくなります。ICE 処理が完了すると状態は Completed になり、成功せずに失敗した場合は Failed になります。状態間の遷移のルールについては、以下で説明します。
5.8. Scheduling Checks (チェックのスケジュール)
チェックはフル実装によってのみ生成されます。ライト実装は、このセクションで説明されている手順をスキップしなければなりません (MUST)。
エージェントは、通常のチェック (ordinary checks) とトリガーされたチェック (triggered checks) を実行します。両方のチェックの生成は、各メディアストリームに対して定期的に発生するタイマーによって制御されます。エージェントは、トリガーされたチェックキュー (triggered check queue) と呼ばれる FIFO キューを維持します。これには、次に利用可能な機会にチェックが送信される候補ペアが含まれています。タイマーが発生すると、エージェントはトリガーされたチェックキューから先頭のペアを削除し、そのペアに対して接続チェックを実行し、候補ペアの状態を In-Progress に設定します。トリガーされたチェックキューにペアがない場合、通常のチェックが送信されます。
セクション 5.7 で説明されているようにエージェントがチェックリストを計算すると、アクティブなチェックリストごとにタイマーを設定します。タイマーは Ta*N 秒ごとに発生します。ここで、N はアクティブなチェックリストの数です（最初は、アクティブなチェックリストは 1 つだけです）。実装は、これよりも頻繁に発生しないようにタイマーを設定する場合があります (MAY)。実装は、各メディアストリームで同時に発生しないように、これらのタイマーを分散させるように注意すべきです (SHOULD)。Ta と再送信タイマー RTO は、セクション 16 で説明されているように計算されます。N を掛けることで、この合計チェックスループットをすべてのアクティブなチェックリスト間で分割できます。最初のタイマーはすぐに発生するため、エージェントはオファー/アンサー交換が行われた瞬間に接続チェックを実行し、続いて Ta 秒後に次のチェックを実行します（アクティブなチェックリストは 1 つしかないため）。
タイマーが発生し、送信するトリガーされたチェックがない場合、エージェントは次のように通常のチェックを選択しなければなりません (MUST)。
-
そのチェックリストで Waiting 状態にある優先順位が最も高いペアを見つけます。
-
そのようなペアがある場合：
- そのペアのローカル候補からそのペアのリモート候補に STUN チェックを送信します。この目的のために STUN リクエストを作成する手順は、セクション 7.1.2 で説明されています。
- 候補ペアの状態を In-Progress に設定します。
-
そのようなペアがない場合：
- そのチェックリストで Frozen 状態にある優先順位が最も高いペアを見つけます。
- そのようなペアがある場合：
- ペアを解凍します。
- そのペアのチェックを実行し、その状態を In-Progress に遷移させます。
- そのようなペアがない場合：
- そのチェックリストのタイマーを終了します。
チェックのメッセージ整合性を計算するために、エージェントは、ピアの SDP から学習したリモートユーザー名フラグメントとパスワードを使用します。ローカルユーザー名フラグメントは、それ自身の候補についてエージェントによって直接知られています。