2. Overview of ICE (ICE の概要)
一般的な ICE 展開では、通信を希望する2つのエンドポイント（RFC 3264 の用語では AGENTS (エージェント) として知られる）があります。それらは、SDP [RFC3264] メッセージのオファー/アンサー交換を実行できるシグナリングプロトコル（SIP など）を介して間接的に通信できます。ICE は SIP のための NAT トラバーサルを意図したものではなく、それは別のメカニズム [RFC5626] を介して提供されると想定されていることに注意してください。ICE プロセスの開始時、エージェントは自身のトポロジを知りません。特に、それらは NAT の背後（または複数の層の NAT の背後）にいる場合もあれば、そうでない場合もあります。ICE により、エージェントは通信可能な1つ以上のパスを見つける可能性がある自身のトポロジに関する十分な情報を発見できます。
図 1 は、ICE 展開の一般的な環境を示しています。2つのエンドポイントには L と R（左と右、コールフローを視覚化するのに役立ちます）というラベルが付いています。L と R はどちらも、認識していない可能性がありますが、それぞれの NAT の背後にいます。NAT の種類とそのプロパティも不明です。エージェント L と R は、L と R の間にメディアセッションを設定することを目的とした SDP メッセージを交換できるオファー/アンサー交換に従事できます。通常、この交換は SIP サーバーを介して行われます。
エージェント、SIP サーバー、および NAT に加えて、ICE は通常、ネットワーク内の STUN または TURN サーバーと連携して使用されます。各エージェントは独自の STUN または TURN サーバーを持つことができ、それらは同じであってもかまいません。
+-------+
| SIP |
+-------+ | Srvr | +-------+
| STUN | | | | STUN |
| Srvr | +-------+ | Srvr |
| | / \ | |
+-------+ / \ +-------+
/ \
/ \
/ \
/ \
/ <- Signaling -> \
/ \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
/ \
+-------+ +-------+
| Agent | | Agent |
| L | | R |
| | | |
+-------+ +-------+
Figure 1: ICE Deployment Scenario
ICE の背後にある基本的な考え方は次のとおりです。各エージェントは、他のエージェントと通信するために使用できるさまざまな候補 TRANSPORT ADDRESSES (トランスポートアドレス)（特定のトランスポートプロトコルの IP アドレスとポートの組み合わせ、この仕様では常に UDP）を持っています。これらには以下が含まれる場合があります。
- 直接接続されたネットワークインターフェイス上のトランスポートアドレス
- NAT のパブリック側の変換されたトランスポートアドレス（"server reflexive" (サーバー反射) アドレス）
- TURN サーバーから割り当てられたトランスポートアドレス（"relayed" (リレー) アドレス）。
潜在的に、L の候補トランスポートアドレスのいずれも、R の候補トランスポートアドレスのいずれかと通信するために使用できます。しかし実際には、多くの組み合わせは機能しません。たとえば、L と R が両方とも NAT の背後にいる場合、それらの直接接続されたインターフェイスアドレスが直接通信できる可能性は低いです（結局のところ、これが ICE が必要な理由です！）。ICE の目的は、どのアドレスのペアが機能するかを発見することです。ICE がこれを行う方法は、機能するものが見つかるまで、すべての可能なペアを（慎重にソートされた順序で）体系的に試すことです。
2.1. Gathering Candidate Addresses (候補アドレスの収集)
ICE を実行するために、エージェントはすべてのアドレス候補を識別する必要があります。CANDIDATE (候補) はトランスポートアドレスであり、特定のトランスポートプロトコル（ここでは UDP のみが指定されています）の IP アドレスとポートの組み合わせです。このドキュメントでは、3種類の候補を定義しており、一部は物理または論理ネットワークインターフェイスから派生し、その他は STUN および TURN を介して発見可能です。当然のことながら、実行可能な1つの候補は、ローカルインターフェイスから直接取得されたトランスポートアドレスです。このような候補は HOST CANDIDATE (ホスト候補) と呼ばれます。ローカルインターフェイスはイーサネットまたは WiFi である可能性があり、仮想プライベートネットワーク (VPN) やモバイル IP (MIP) などのトンネルメカニズムを介して取得されたものである可能性もあります。すべての場合において、このようなネットワークインターフェイスは、エージェントにはポート（したがって候補）を割り当てることができるローカルインターフェイスとして表示されます。
エージェントがマルチホームの場合、各 IP アドレスから候補を取得します。エージェントに対する IP ネットワーク上の PEER (ピア)（セッション内の他のエージェント）の位置に応じて、エージェントはそれらの IP アドレスの1つ以上を介してピアから到達可能である場合があります。たとえば、プライベート net 10 ネットワーク (I1) 上にローカル IP アドレスを持ち、パブリックインターネット (I2) に接続された2番目の IP アドレスを持つエージェントを考えてみましょう。I1 からの候補は、同じプライベート net 10 ネットワーク上のピアと通信する場合に直接到達可能であり、I2 からの候補は、パブリックインターネット上のピアと通信する場合に直接到達可能です。オファーを送信する前にどの IP アドレスが機能するかを推測しようとするのではなく、オファーエージェントは両方の候補をオファーに含めます。
次に、エージェントは STUN または TURN を使用して追加の候補を取得します。これらには2つのフレーバーがあります。NAT のパブリック側の変換されたアドレス (SERVER REFLEXIVE CANDIDATES (サーバー反射候補)) と、TURN サーバー上のアドレス (RELAYED CANDIDATES (リレー候補)) です。TURN サーバーが利用される場合、両方のタイプの候補が TURN サーバーから取得されます。STUN サーバーのみが利用される場合、サーバー反射候補のみがそれらから取得されます。これらの候補とホスト候補の関係を図 2 に示します。この図では、両方のタイプの候補が TURN を使用して発見されています。図では、表記 X:x は IP アドレス X と UDP ポート x を意味します。
To Internet
|
|
| /------------ Relayed
Y:y | / Address
+--------+
| |
| TURN |
| Server |
| |
+--------+
|
|
| /------------ Server
X1':x1'|/ Reflexive
+------------+ Address
| NAT |
+------------+
|
| /------------ Local
X:x |/ Address
+--------+
| |
| Agent |
| |
+--------+
Figure 2: Candidate Relationships
エージェントが IP アドレスとポート X:x から TURN Allocate リクエストを送信すると、NAT（存在すると仮定）はバインディング X1':x1' を作成し、このサーバー反射候補をホスト候補 X:x にマッピングします。ホスト候補から送信された発信パケットは、NAT によってサーバー反射候補に変換されます。サーバー反射候補に送信された着信パケットは、NAT によってホスト候補に変換され、エージェントに転送されます。特定のサーバー反射候補に関連付けられたホスト候補を BASE (ベース) と呼びます。
注：「ベース」とは、エージェントが特定の候補のために送信する元のアドレスを指します。したがって、縮退したケースとして、ホスト候補もベースを持ちますが、それはホスト候補と同じです。
エージェントと TURN サーバーの間に複数の NAT がある場合、TURN リクエストは各 NAT 上にバインディングを作成しますが、最も外側のサーバー反射候補（TURN サーバーに最も近いもの）のみがエージェントによって発見されます。エージェントが NAT の背後にいない場合、ベース候補はサーバー反射候補と同じになり、サーバー反射候補は冗長であり、排除されます。
その後、Allocate リクエストが TURN サーバーに到着します。TURN サーバーはローカル IP アドレス Y からポート y を割り当て、Allocate レスポンスを生成して、このリレー候補をエージェントに通知します。TURN サーバーはまた、Allocate リクエストのソースのトランスポートアドレスを Allocate レスポンスにコピーすることにより、サーバー反射候補 X1':x1' をエージェントに通知します。TURN サーバーはパケットリレーとして機能し、L と R の間のトラフィックを転送します。L にトラフィックを送信するために、R は Y:y の TURN サーバーにトラフィックを送信し、TURN サーバーはそれを X1':x1' に転送します。これは NAT を通過し、そこで X:x にマッピングされて L に配信されます。
STUN サーバーのみが利用される場合、エージェントは STUN サーバーに STUN Binding リクエスト [RFC5389] を送信します。STUN サーバーは、Binding リクエストのソースのトランスポートアドレスを Binding レスポンスにコピーすることにより、サーバー反射候補 X1':x1' をエージェントに通知します。
2.2. Connectivity Checks (接続性チェック)
L がすべての候補を収集すると、それらを優先順位の高い順に並べ替え、シグナリングチャネルを介して R に送信します。候補は SDP オファーの属性で運ばれます。R がオファーを受信すると、同じ収集プロセスを実行し、独自の候補リストで応答します。このプロセスの終わりに、各エージェントは自身の候補とピアの候補の両方の完全なリストを持ちます。それらをペアにして、CANDIDATE PAIRS (候補ペア) を作成します。どのペアが機能するかを確認するために、各エージェントは一連の CHECKS (チェック) をスケジュールします。各チェックは、ローカル候補からリモート候補に STUN リクエストを送信することによって、クライアントが特定の候補ペアに対して実行する STUN リクエスト/レスポンス トランザクションです。
接続性チェックの基本原則は単純です。
- 候補ペアを優先順位順に並べ替えます。
- 各候補ペアに対して優先順位順にチェックを送信します。
- 他のエージェントから受信したチェックを確認します。
両方のエージェントが候補ペアに対してチェックを実行すると、結果は4ウェイハンドシェイクになります。
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
Figure 3: Basic Connectivity Check
STUN リクエストは、メディア（たとえば、RTP および RTCP）に使用されるのとまったく同じ IP アドレスとポートとの間で送信されることに注意することが重要です。したがって、エージェントは、受信したポートではなく、パケットの内容を使用して STUN と RTP/RTCP を逆多重化します。幸いなことに、この逆多重化は、特に RTP および RTCP の場合は簡単に行うことができます。
接続性チェックには STUN Binding リクエストが使用されるため、STUN Binding レスポンスには、エージェントとそのピアの間の NAT のパブリック側にあるエージェントの変換されたトランスポートアドレスが含まれます。このトランスポートアドレスがエージェントがすでに学習した他の候補と異なる場合、それは PEER REFLEXIVE CANDIDATE (ピア反射候補) と呼ばれる新しい候補を表し、ICE によって他の候補と同様にテストされます。
最適化として、R が L のチェックメッセージを取得するとすぐに、R は同じ候補ペアで L に送信される接続性チェックメッセージをスケジュールします。これは有効な候補を見つけるプロセスを加速し、TRIGGERED CHECK (トリガーされたチェック) と呼ばれます。
このハンドシェイクの終わりに、L と R の両方が、両方向でエンドツーエンドでメッセージを送信（および受信）できることを知ります。
2.3. Sorting Candidates (候補のソート)
上記のアルゴリズムはすべての候補ペアを検索するため、機能するペアが存在する場合、候補がどのような順序で試行されても最終的にそれが見つかります。より速い（そしてより良い）結果を生成するために、候補は指定された順序でソートされます。結果として得られるソートされた候補ペアのリストは、CHECK LIST (チェックリスト) と呼ばれます。アルゴリズムはセクション 4.1.2 で説明されていますが、2つの一般的な原則に従います。
- 各エージェントは候補に数値の優先順位を与え、これは候補とともにピアに送信されます。
- ローカルとリモートの優先順位が組み合わされ、各エージェントが候補ペアに対して同じ順序を持つようになります。
2番目のプロパティは、L と R の前に NAT がある場合に ICE を機能させるために重要です。多くの場合、NAT は、NAT の背後にいるエージェントがそのホストに向けてパケットを送信するまで、ホストからのパケットの侵入を許可しません。したがって、双方がそれぞれの NAT を介してチェックを送信するまで、各方向の ICE チェックは成功しません。
エージェントは、リスト上の次の候補ペアに対する STUN リクエストを定期的に送信することにより、このチェックリストを処理します。これらは ORDINARY CHECKS (通常のチェック) と呼ばれます。
一般に、優先順位アルゴリズムは、類似したタイプの候補が類似した優先順位を取得し、より直接的なルート（つまり、より少ないメディアリレーとより少ない NAT を通過するルート）が間接的なルート（より多くのメディアリレーとより多くの NAT を持つルート）よりも優先されるように設計されています。ただし、これらのガイドライン内では、エージェントはアルゴリズムを調整する方法についてかなりの裁量権を持っています。
2.4. Frozen Candidates (凍結された候補)
前の説明では、エージェントが1つの COMPONENT (コンポーネント)（単一のトランスポートアドレスを必要とするメディアストリームの一部。メディアストリームは複数のコンポーネントを必要とする場合があり、メディアストリーム全体が機能するには、その各々が機能する必要があります）でメディアセッションを確立したい場合のみを取り上げました。通常（たとえば、RTP と RTCP の場合）、エージェントは実際には複数のフローの接続を確立する必要があります。
ネットワークプロパティは、各コンポーネントで非常に類似している可能性があります（特に RTP と RTCP は同じ IP アドレスから送受信されるため）。通常、別のコンポーネントの最適な候補を決定するために、あるメディアコンポーネントからの情報を活用することが可能です。ICE は、"frozen candidates" (凍結された候補) と呼ばれるメカニズムを使用してこれを行います。
各候補は、その FOUNDATION (ファウンデーション) と呼ばれるプロパティに関連付けられています。2つの候補が「類似」している場合（同じタイプであり、同じホスト候補と STUN サーバーから同じプロトコルを使用して取得された場合）、それらは同じファウンデーションを持ちます。そうでない場合、それらのファウンデーションは異なります。候補ペアもファウンデーションを持ち、これは単にその2つの候補のファウンデーションを連結したものです。最初は、一意のファウンデーションを持つ候補ペアのみがテストされます。他の候補ペアは "frozen" (凍結) とマークされます。候補ペアの接続性チェックが成功すると、同じファウンデーションを持つ他の候補ペアが凍結解除されます。これにより、表面的にはより魅力的であるが実際には失敗する可能性が高いコンポーネントの繰り返しチェックが回避されます。
ここでは説明のために「凍結」を別のメカニズムとして説明しましたが、実際にはそれは ICE の不可欠な部分であり、ICE 優先順位付けアルゴリズムは、正しい候補が凍結解除され、正しい順序でチェックされることを自動的に保証します。
2.5. Security for Checks (チェックのセキュリティ)
ICE は、2つのエージェント間でメディアを送信するためにどのアドレスを使用できるかを発見するために使用されるため、プロセスが乗っ取られて誤った場所にメディアが送信されないようにすることが重要です。各 STUN 接続性チェックは、シグナリングチャネルで交換されたキーを使用して計算されたメッセージ認証コード (MAC) によってカバーされます。この MAC はメッセージの整合性とデータ発信元認証を提供し、攻撃者が接続性チェックメッセージを偽造または変更するのを防ぎます。さらに、SIP [RFC3261] 発信者が ICE を使用しており、その呼び出しがフォークする場合、ICE 交換は各フォーク受信者と独立して行われます。このような場合、シグナリングで交換されたキーは、各 ICE 交換を各フォーク受信者に関連付けるのに役立ちます。
2.6. Concluding ICE (ICE の完了)
ICE チェックは特定の順序で実行されるため、優先順位の高い候補ペアが最初にチェックされ、その後に優先順位の低い候補ペアが続きます。ICE を完了する1つの方法は、各メディアストリームの各コンポーネントのチェックが正常に完了するとすぐに勝利を宣言することです。実際、これは合理的なアルゴリズムであり、その詳細については以下で説明します。ただし、パケット損失により、優先順位の高いチェックの完了に時間がかかる可能性があります。その場合、ICE を少し長く実行させると、より良い結果が得られる可能性があります。ただし、より根本的には、この仕様で定義されている優先順位付けは「最適」な結果をもたらさない可能性があります。例として、低遅延のメディアパスを選択することが目的の場合、リレーの使用は遅延が高くなる可能性があるというヒントですが、それはヒントにすぎません。実際のラウンドトリップ時間 (RTT) 測定を行うことができ、優先順位の低いペアが優先順位の高いペアよりも実際には優れていることが示される場合があります。
したがって、ICE はエージェントの1つを CONTROLLING AGENT (制御エージェント) の役割に割り当て、もう1つを CONTROLLED AGENT (被制御エージェント) の役割に割り当てます。制御エージェントは、有効な候補ペアの中からメディアに使用する候補ペアを指名します。これは、REGULAR NOMINATION (通常の指名) または AGGRESSIVE NOMINATION (積極的な指名) の2つの方法のいずれかで行うことができます。
通常の指名では、制御エージェントは、各メディアストリームに対して少なくとも1つの有効な候補ペアが見つかるまでチェックを続行させます。その後、有効なものの中から選択し、NOMINATED (指名された) 候補ペアで2番目の STUN リクエストを送信しますが、今回はこのペアが使用のために指名されたことをピアに伝えるフラグが設定されています。これを図 4 に示します。
L R
- -
STUN request -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
STUN request + flag -> \ L's
<- STUN response / check
Figure 4: Regular Nomination
フラグ付きの STUN トランザクションが完了すると、双方はそのメディアストリームの将来のチェックをキャンセルします。ICE はこのペアを使用してメディアを送信します。ICE エージェントがメディアに使用しているペアは、SELECTED PAIR (選択されたペア) と呼ばれます。
積極的な指名では、制御エージェントは送信するすべての STUN リクエストにフラグを入れます。このようにして、最初のチェックが成功すると、そのメディアストリームの ICE 処理が完了し、制御エージェントは2番目の STUN リクエストを送信する必要がありません。選択されたペアは、チェックが成功した最も優先順位の高い有効なペアになります。積極的な指名は通常の指名よりも高速ですが、柔軟性は低くなります。積極的な指名を図 5 に示します。
L R
- -
STUN request + flag -> \ L's
<- STUN response / check
<- STUN request \ R's
STUN response -> / check
Figure 5: Aggressive Nomination
すべてのメディアストリームが完了すると、メディアストリームの m 行と c 行の候補（DEFAULT CANDIDATES (デフォルト候補) と呼ばれる）が ICE の SELECTED CANDIDATES (選択された候補) と一致しない場合、制御エンドポイントは更新されたオファーを送信します。
ICE が完了すると、いずれかのエージェントによって、1つまたはすべてのメディアストリームに対していつでも再開できます。これは、再開を示す更新されたオファーを送信することによって行われます。
2.7. Lite Implementations (ライト実装)
ICE を通話で使用するには、両方のエージェントがそれをサポートする必要があります。ただし、特定のエージェントは常にパブリックインターネットに接続されており、任意の通信相手からパケットを受信できるパブリック IP アドレスを持っています。これらのデバイスが ICE をサポートしやすくするために、ICE は LITE (ライト) と呼ばれる特別なタイプの実装を定義しています（通常の FULL (フル) 実装とは対照的です）。ライト実装は候補を収集しません。メディアストリームのホスト候補のみが含まれます。ライトエージェントは、接続性チェックに応答できる必要がありますが、接続性チェックを生成したり、ステートマシンを実行したりしません。ライト実装がフル実装と接続する場合、フルエージェントは制御エージェントの役割を果たし、ライトエージェントは被制御の役割を果たします。2つのライト実装が接続する場合、チェックは送信されません。
ライト実装が適切な場合に関するガイダンスについては、付録 A の議論を参照してください。
ライト実装は、フル実装への足がかりを提供するためにこの仕様に追加されたことに注意することが重要です。常にパブリックインターネットに接続されているデバイスであっても、達成可能であればフル実装が望ましいです。