Last active
February 7, 2020 10:20
-
-
Save shinyoshiaki/710a6361ca92438c42fc429895d5b95f to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 1.はじめに | |
| RFC 3264 [RFC3264]は、マルチメディアセッションの確立を目的としたSession Description Protocol（SDP）メッセージの2フェーズ交換[RFC4566]を定義しています。このオファー/アンサーメカニズムは、セッション開始プロトコル（SIP）[RFC3261]などのプロトコルで使用されます。 | |
| オファー/アンサーを使用するプロトコルは、ネットワークアドレス変換器（NAT）を介して操作するのが困難です。メディアパケットのフローを確立することが目的であるため、メッセージ内でメディアソースおよびシンクのIPアドレスとポートを運ぶ傾向があります。これは、NAT [RFC3235]で問題があることが知られています。また、プロトコルは参加者間で直接メディアフローを作成しようとするため、参加者間にアプリケーションレイヤーの仲介はありません。これは、メディアの遅延を減らし、パケット損失を減らし、アプリケーションを展開する運用コストを削減するために行われます。ただし、これをNATで実現することは困難です。この理由の完全な取り扱いは、この仕様の範囲外です。 | |
| これらのプロトコルがNATを介して動作できるようにするための多数のソリューションが定義されています。これらには、アプリケーション層ゲートウェイ（ALG）、ミドルボックス制御プロトコル[RFC3303]、元のUDPスルーNAT（STUN）[RFC3489]仕様、およびレルム固有IP [RFC3102] [RFC3103]が必要なセッション記述拡張が含まれます。リアルタイム制御プロトコル（RTCP）[RFC3605]のセッション記述プロトコル（SDP）[RFC4566]属性など、それらを機能させます。残念ながら、これらの手法にはすべて長所と短所があり、ネットワークトポロジによっては最適化されますが、他のネットワークトポロジでは不十分な選択になります。その結果、管理者と実装者は、ソリューションが展開されるネットワークのトポロジについて推測を行っています。これは、システムに複雑さと脆弱性をもたらします。 | |
| この仕様は、オファー/アンサーモデルによって確立されたUDPベースのメディアストリーム（TCP [ICE-TCP]などの他のトランスポートプロトコルを処理するようにICEを拡張できます）のNATトラバーサルの技術として、Interactive Connectivity Establishment（ICE）を定義します。ICEはオファー/アンサーモデルの拡張であり、SDPオファーおよびアンサーに多数のIPアドレスとポートを含めることで機能し、その後、ピアツーピア接続チェックによって接続性がテストされます。SDPに含まれるIPアドレスとポート、および接続性チェックは、改訂されたSTUN仕様[RFC5389]を使用して実行され、現在はNATのSession Traversal Utilitiesに名前が変更されています。新しい名前と新しい仕様は、スタンドアロンのNATトラバーサルソリューションではなく、他のNATトラバーサル技術（つまりICE）で使用されるツールとしての新しい役割を反映しています。元のSTUN仕様がそうであったように。ICEは、STUNの拡張であるNAT（TURN）[RFC5766]周辺のリレーを使用したトラバーサルも利用します。ICEは各メディアストリームに対して多数のIPアドレスとポートを交換するため、マルチホームおよびデュアルスタックホストのアドレス選択も可能にします。このため、RFC 4091 [RFC4091]および[RFC4092]は廃止されます。 | |
| 2. ICEの概要 | |
| 一般的なICE展開では、通信する2つのエンドポイント（RFC 3264の用語でAGENTSとして知られています）があります。彼らは、SDP [RFC3264]メッセージのオファー/アンサー交換を実行できる、いくつかのシグナリングプロトコル（SIPなど）を介して間接的に通信できます。ICEは、別のメカニズム[RFC5626]を介して提供されると想定されるSIPのNATトラバーサルを対象としていないことに注意してください。ICEプロセスの開始時には、エージェントは自分のトポロジーを知らない。特に、NAT（または複数層のNAT）の背後にある場合とそうでない場合があります。ICEを使用すると、エージェントはトポロジに関する十分な情報を発見して、通信可能な1つ以上のパスを潜在的に見つけることができます。 | |
| 図1は、ICE展開の一般的な環境を示しています。2つのエンドポイントには、LおよびRというラベルが付けられています（左右の場合、コールフローの視覚化に役立ちます）。LとRは両方とも、それぞれのNATの背後にありますが、認識していない場合があります。NATのタイプとそのプロパティも不明です。エージェントLとRは、SDPメッセージを交換できるオファー/アンサー交換を行うことができます。その目的は、LとRの間にメディアセッションをセットアップすることです。通常、この交換はSIPサーバーを介して行われます。エージェント、SIPサーバー、NATに加えて、ICEは通常、ネットワーク内のSTUNまたはTURNサーバーと連携して使用されます。各エージェントは、独自のSTUNまたはTURNサーバーを持つことも、同じサーバーにすることもできます。 | |
| + ------- + | SIP | + ------- + | Srvr | + ------- + | スタン| | | | スタン| | Srvr | + ------- + | Srvr | | | / \ | | + ------- + / \ + ------- + / \ / \ / \ / \ / <-シグナリング-> \ / \ / \ + -------- + + -------- + | NAT | | NAT | + -------- + + -------- + / \ / \ / \ + ------- + + ------- + | エージェント| | エージェント| | L | | R | | | | | + ------- + + ------- + | |
| 図1：ICE展開シナリオ | |
| ICEの背後にある基本的な考え方は次のとおりです。各エージェントには、他のエージェントと通信するために使用できるさまざまな候補のトランスポートアドレス（特定のトランスポートプロトコルのIPアドレスとポートの組み合わせ、この仕様では常にUDP）があります。これらには以下が含まれます。 | |
| o直接接続されたネットワークインターフェイスのトランスポートアドレス | |
| o NATのパブリック側の変換されたトランスポートアドレス（「サーバーの再帰」アドレス） | |
| o TURNサーバーから割り当てられたトランスポートアドレス（「リレーアドレス」）。 | |
| 潜在的に、Lの候補トランスポートアドレスのいずれかを使用して、Rの候補トランスポートアドレスのいずれかと通信できます。ただし、実際には、多くの組み合わせは機能しません。たとえば、LとRの両方がNATの背後にある場合、直接接続されたインターフェイスアドレスが直接通信できる可能性は低いです（これが、ICEが必要な理由です！）。ICEの目的は、どのアドレスのペアが機能するかを発見することです。ICEがこれを行う方法は、機能する1つ以上を見つけるまで、考えられるすべてのペアを体系的に（慎重にソートされた順序で）試行することです。 | |
| 2.1。候補者住所の収集 | |
| ICEを実行するには、エージェントはすべてのアドレス候補を識別する必要があります。CANDIDATEはトランスポートアドレスです。特定のトランスポートプロトコルのIPアドレスとポートの組み合わせです（ここではUDPのみを指定します）。このドキュメントでは、3種類の候補を定義します。物理または論理ネットワークインターフェイスから派生したものと、STUNおよびTURNを介して検出可能なものがあります。当然、実行可能な候補の1つは、ローカルインターフェイスから直接取得したトランスポートアドレスです。このような候補は、ホスト候補と呼ばれます。ローカルインターフェイスは、イーサネットまたはWiFiであるか、仮想プライベートネットワーク（VPN）やモバイルIP（MIP）などのトンネルメカニズムを介して取得されるものです。すべての場合において、このようなネットワークインターフェースは、ポート（および候補）を割り当てることができるローカルインターフェースとしてエージェントに見えます。 | |
| エージェントがマルチホームの場合、各IPアドレスから候補を取得します。エージェントに関連するIPネットワーク上のPEER（セッション内の他のエージェント）の場所によっては、1つ以上のIPアドレスを介してピアからエージェントに到達できる場合があります。たとえば、プライベートネット10ネットワーク（I1）にローカルIPアドレスを持ち、パブリックインターネット（I2）に接続されている2番目のエージェントがあるとします。I1の候補者は、同じプライベートネット10ネットワーク上のピアと通信するときに直接到達できますが、I2の候補者は、パブリックインターネット上のピアと通信するときに直接到達できます。オファーを送信する前にどのIPアドレスが機能するかを推測するのではなく、オファーエージェントはオファーに両方の候補を含めます。 | |
| 次に、エージェントはSTUNまたはTURNを使用して追加の候補を取得します。これらには2つのフレーバーがあります。NATのパブリック側の変換済みアドレス（サーバーリフレクティブ候補）とTURNサーバーのアドレス（リレー候補）です。TURNサーバーを使用すると、両方のタイプの候補がTURNサーバーから取得されます。STUNサーバーのみが使用されている場合、サーバー反射候補のみがそれらから取得されます。これらの候補とホスト候補の関係を図2に示します。この図では、両方のタイプの候補がTURNを使用して検出されます。図では、表記X：xはIPアドレスXとUDPポートxを意味します。 | |
| インターネットへ | |
| | | | / ------------リレーされたY：y | /住所+ -------- + | | | TURN | | サーバー| | | + -------- + | | | / ------------サーバーX1 '：x1' | /再帰+ ------------ +アドレス| NAT | + ------------ + | | / ------------ローカルX：x | /アドレス+ -------- + | | | エージェント| | | + -------- + | |
| 図2：候補者の関係 | |
| エージェントがIPアドレスとポートX：xからTURN Allocate要求を送信すると、NAT（1つが存在すると仮定）はバインディングX1 '：x1'を作成し、このサーバー反射候補をホスト候補X：xにマッピングします。ホスト候補から送信された発信パケットは、NATによってサーバーの再帰候補に変換されます。サーバーの再帰候補に送信された着信パケットは、NATによってホスト候補に変換され、エージェントに転送されます。特定のサーバー再帰候補に関連付けられたホスト候補をBASEと呼びます。 | |
| 注：「ベース」とは、特定の候補者に対してエージェントが送信するアドレスを指します。したがって、縮退した場合、ホスト候補にもベースがありますが、ホスト候補はホスト候補と同じです。 | |
| エージェントとTURNサーバーの間に複数のNATがある場合、TURN要求は各NATにバインディングを作成しますが、最も外側のサーバーの再帰候補（TURNに最も近い候補）のみを作成します | |
| サーバー）はエージェントによって検出されます。エージェントがNATの背後にない場合、ベース候補はサーバー反射候補と同じになり、サーバー反射候補は冗長であり、除去されます。 | |
| 次に、割り当て要求が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バインディング要求[RFC5389]をSTUNサーバーに送信します。STUNサーバーは、Binding要求のソーストランスポートアドレスをBinding応答にコピーすることにより、エージェントにサーバー再帰候補X1 '：x1'を通知します。 | |
| 2.2。接続性チェック | |
| Lがすべての候補を収集すると、それらを最高から最低の優先順位で並べ、シグナリングチャネルを介してRに送信します。候補は、SDPオファーの属性に含まれています。Rはオファーを受信すると、同じ収集プロセスを実行し、独自の候補リストで応答します。このプロセスの最後に、各エージェントには候補とピアの候補の両方の完全なリストがあります。それらはペアになり、候補ペアになります。どのペアが機能するかを確認するために、各エージェントは一連のチェックをスケジュールします。各チェックは、ローカル候補からリモート候補にSTUN要求を送信することにより、クライアントが特定の候補ペアに対して実行するSTUN要求/応答トランザクションです。 | |
| 接続性チェックの基本原則は簡単です。 | |
| 1.候補ペアを優先順に並べ替えます。 | |
| 2.各候補者ペアに優先順位で小切手を送信します。 | |
| 3.他のエージェントから受信した確認を確認します。 | |
| 両方のエージェントが候補ペアのチェックを実行すると、結果は4ウェイハンドシェイクになります。 | |
| LR--STUNリクエスト-> \ Lの<-STUNレスポンス/チェック | |
| <-STUNリクエスト\ RのSTUNレスポンス-> /チェック | |
| 図3：基本的な接続チェック | |
| STUN要求は、メディア（RTPやRTCPなど）に使用されるものとまったく同じIPアドレスとポートとの間で送受信されることに注意することが重要です。その結果、エージェントは、受信先のポートではなく、パケットのコンテンツを使用してSTUNとRTP / RTCPを逆多重化します。幸いなことに、特にRTPとRTCPの場合、この逆多重化は簡単です。 | |
| STUNバインディング要求は接続チェックに使用されるため、STUNバインディング応答には、エージェントとそのピア間のNATのパブリック側にあるエージェントのトランスポートアドレスが含まれます。このトランスポートアドレスがエージェントが既に学習した他の候補と異なる場合、それはPEER REFLEXIVE CANDIDATEと呼ばれる新しい候補を表し、他の候補とまったく同じようにICEによってテストされます。 | |
| 最適化として、RはLのチェックメッセージを取得するとすぐに、Rは同じ候補ペアのLに接続チェックメッセージを送信するようにスケジュールします。これにより、有効な候補を見つけるプロセスが加速され、トリガーチェックと呼ばれます。 | |
| このハンドシェイクの終わりに、LとRの両方は、両方向でメッセージをエンドツーエンドで送信（および受信）できることを知っています。 | |
| 2.3。候補者の並べ替え | |
| 上記のアルゴリズムはすべての候補ペアを検索するため、作業ペアが存在する場合、候補が試行された順序に関係なく最終的に検出されます。結果をより速く（より良い）生成するために、候補は指定された順序でソートされます。ソートされた候補ペアの結果のリストは、チェックリストと呼ばれます。アルゴリズムについてはセクション4.1.2で説明しますが、2つの一般原則に従います。 | |
| o各エージェントは、候補者に数値の優先度を与えます。優先度は候補とともにピアに送信されます。oローカルとリモートの優先順位は、各エージェントが候補ペアに対して同じ順序になるように結合されます。 | |
| 2番目のプロパティは、LおよびRの前にNATがあるときにICEを動作させるために重要です。多くの場合、NATは、NATの背後のエージェントがそのホストにパケットを送信するまで、ホストからのパケットを許可しません。その結果、各方向のICEチェックは、両側がそれぞれのNATを介してチェックを送信するまで成功しません。 | |
| エージェントは、リスト上の次の候補ペアに対するSTUN要求を定期的に送信することにより、このチェックリストを処理します。これらは通常チェックと呼ばれます。 | |
| 一般に、優先度アルゴリズムは、同様のタイプの候補が同様の優先度を取得し、より多くの直接ルート（つまり、より少ないメディアリレーとより少ないNAT）が間接的なもの（より多くのメディアリレーとより多くのNATを持つもの）よりも優先されるように設計されています）。ただし、これらのガイドラインでは、エージェントはアルゴリズムの調整方法についてかなりの裁量権を持っています。 | |
| 2.4。凍結候補者 | |
| 前述の説明は、エージェントが1つのコンポーネント（単一のトランスポートアドレスを必要とするメディアストリームの一部、メディアストリームが複数のコンポーネントを必要とし、それぞれがメディアストリームに対して機能する必要がある場合）全体として仕事になります）。通常（たとえば、RTPおよびRTCPを使用）、エージェントは実際に複数のフローの接続を確立する必要があります。 | |
| ネットワークプロパティは、各コンポーネントで非常によく似ています（特に、RTPとRTCPは同じIPアドレスから送受信されるため）。通常、1つのメディアコンポーネントからの情報を活用して、別のメディアコンポーネントの最適な候補を決定することができます。ICEは、「凍結候補」と呼ばれるメカニズムを使用してこれを行います。 | |
| 各候補には、FOUNDATIONと呼ばれるプロパティが関連付けられています。「類似」する場合、2つの候補は同じ基盤を持ちます。同じタイプで、同じホスト候補と同じプロトコルを使用するSTUNサーバーから取得されます。それ以外の場合、その基盤は異なります。候補者ペアにも基礎があります。これは、2つの候補者の基礎を連結しただけです。最初に、一意の基盤を持つ候補ペアのみがテストされます。他の候補ペアは「凍結」とマークされています。候補ペアの接続チェックが成功すると、他の候補ペアは | |
| 同じ基盤は凍結されていません。これにより、表面的にはより魅力的ですが、実際には失敗する可能性が高いコンポーネントの繰り返しのチェックが回避されます。 | |
| ここでは「凍結」を説明目的の別のメカニズムとして説明しましたが、実際にはICEの不可欠な部分であり、ICE優先順位付けアルゴリズムにより、正しい候補が凍結されず正しい順序でチェックされることが自動的に保証されます。 | |
| 2.5。チェックのセキュリティ | |
| ICEは2つのエージェント間でメディアを送信するために使用できるアドレスを検出するために使用されるため、プロセスをハイジャックしてメディアを間違った場所に送信できないようにすることが重要です。各STUN接続チェックは、シグナリングチャネルで交換されたキーを使用して計算されたメッセージ認証コード（MAC）でカバーされます。このMACはメッセージの整合性とデータ発信元の認証を提供するため、攻撃者が接続チェックメッセージを偽造または変更するのを防ぎます。さらに、SIP [RFC3261]の発信者がICEを使用しており、それらのコールフォークがある場合、ICE交換は各フォークされた受信者と独立して行われます。このような場合、シグナリングで交換されるキーは、各ICE交換を各分岐受信者に関連付けるのに役立ちます。 | |
| 2.6。ICEの終了 | |
| ICEチェックは特定の順序で実行されるため、優先度の高い候補ペアが最初にチェックされ、次に優先度の低い候補ペアがチェックされます。ICEを終了する1つの方法は、各メディアストリームの各コンポーネントのチェックが正常に完了したらすぐに勝利を宣言することです。実際、これは合理的なアルゴリズムであり、その詳細は以下に記載されています。ただし、パケットの損失により、優先度の高いチェックが完了するまでに時間がかかる可能性があります。その場合、ICEの実行をもう少し長くすると、より良い結果が得られる場合があります。ただし、より基本的には、この仕様で定義されている優先順位付けでは、「最適な」結果が得られない場合があります。例として、低レイテンシのメディアパスを選択することを目的とする場合、リレーの使用はレイテンシが高くなる可能性のあるヒントですが、それは単なるヒントにすぎません。 | |
| その結果、ICEは、制御エージェントの役割のエージェントの1つと、制御エージェントのもう1つを割り当てます。制御エージェントは、有効なものの中でメディアに使用される候補のペアを指定します。これは、2つの方法のいずれかで行うことができます-通常の指名または積極的な指名を使用します。 | |
| 通常の指名では、制御エージェントは、各メディアストリームに対して少なくとも1つの有効な候補ペアが見つかるまでチェックを続行します。次に、有効なものの中から選択し、NOMINATED候補ペアで2番目のSTUN要求を送信しますが、今回は、このペアが使用にノミネートされたことをピアに通知するためにフラグを設定します。これを図4に示します。 | |
| LR--STUNリクエスト-> \ Lの<-STUNレスポンス/チェック | |
| <-STUNリクエスト\ RのSTUNレスポンス-> /チェック | |
| STUN要求+フラグ-> \ Lの<-STUN応答/チェック | |
| 図4：定期的な推薦 | |
| フラグ付きのSTUNトランザクションが完了すると、両側はそのメディアストリームの今後のチェックをキャンセルします。ICEはこのペアを使用してメディアを送信します。ICEエージェントがメディアに使用しているペアは、SELECTED PAIRと呼ばれます。 | |
| 積極的な指名では、制御エージェントは送信するすべてのSTUN要求にフラグを入れます。この方法では、最初のチェックが成功すると、そのメディアストリームのICE処理が完了し、制御エージェントは2番目のSTUN要求を送信する必要がありません。選択されたペアは、チェックが成功した最も優先度の高い有効なペアになります。積極的な指名は通常の指名よりも速くなりますが、柔軟性は低下します。積極的な指名を図5に示します。 | |
| LR--STUNリクエスト+フラグ-> \ Lの<-STUNレスポンス/チェック | |
| <-STUNリクエスト\ RのSTUNレスポンス-> /チェック | |
| 図5：積極的な指名 | |
| すべてのメディアストリームが完了すると、メディアストリームのmおよびc行の候補（デフォルトの候補と呼ばれる）がICEの選択された候補と一致しない場合、制御エンドポイントは更新されたオファーを送信します。ICEが終了すると、いずれかのエージェントが1つまたはすべてのメディアストリームに対していつでも再起動できます。これは、再起動を示す更新されたオファーを送信することにより行われます。 | |
| 2.7。Liteの実装 | |
| ICEが通話で使用されるためには、両方のエージェントがそれをサポートする必要があります。ただし、特定のエージェントは常にパブリックインターネットに接続され、通信員からパケットを受信できるパブリックIPアドレスを持ちます。これらのデバイスがICEをサポートしやすくするために、ICEは（通常のFULL実装とは対照的に）LITEと呼ばれる特別なタイプの実装を定義します。簡易実装では候補者を集めません。メディアストリームのホスト候補のみが含まれます。Liteエージェントは接続チェックを生成したり、状態マシンを実行したりしませんが、接続チェックに応答できる必要があります。ライトの実装が完全な実装に接続すると、完全なエージェントが制御エージェントの役割を引き受け、ライトエージェントが制御された役割を引き受けます。2つのライト実装が接続されると、 | |
| ライトの実装が適切な場合のガイダンスについては、付録Aの説明を参照してください。 | |
| 完全な実装への足掛かりを提供するために、この仕様にライト実装が追加されたことに注意することが重要です。常にパブリックインターネットに接続されているデバイスであっても、実現可能な場合は完全な実装が望ましいです。 | |
| 3.用語 | |
| このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」はRFC 2119 [RFC2119]で説明されているように解釈されます。 | |
| 読者は、オファー/アンサーモデル[RFC3264]、STUN [RFC5389]、およびUDPのNAT動作要件[RFC4787]で定義されている用語に精通している必要があります。 | |
| この仕様では、次の追加の用語を使用しています。 | |
| エージェント：RFC 3264で定義されているように、エージェントはオファー/アンサー交換に関係するプロトコル実装です。オファー/アンサー交換には2つのエージェントが関与します。 | |
| ピア：セッション内のエージェントの1人から見ると、そのピアは他のエージェントです。具体的には、提供者の観点から見ると、ピアは回答者です。回答者の観点から見ると、ピアは提供者です。 | |
| トランスポートアドレス：IPアドレスとトランスポートプロトコル（UDPやTCPなど）ポートの組み合わせ。 | |
| 候補：メディアを受け取るための潜在的な連絡先となるトランスポートアドレス。候補者には、タイプ（サーバー反射型、リレー型またはホスト型）、優先度、基盤、およびベースのプロパティもあります。 | |
| コンポーネント：コンポーネントは、単一のトランスポートアドレスを必要とするメディアストリームの一部です。メディアストリームには複数のコンポーネントが必要な場合があり、各コンポーネントは、メディアストリーム全体が機能するために機能する必要があります。RTPに基づくメディアストリームの場合、メディアストリームごとに2つのコンポーネントがあります。1つはRTP用で、もう1つはRTCP用です。 | |
| ホスト候補：ホスト上のIPアドレスから特定のポートにバインドすることにより取得された候補。これには、仮想プライベートネットワーク（VPN）やレルム固有IP（RSIP）[RFC3102]（オペレーティングシステムレベルで存在する）から取得したものなど、物理インターフェイスと論理アドレスのIPアドレスが含まれます。 | |
| サーバー再帰候補：IPアドレスとポートが、NATを介してサーバーにパケットを送信したときに、NATによってエージェントに割り当てられたバインディングである候補。サーバー反射候補は、バインド要求を使用するSTUNサーバー、または中継サーバー候補とサーバー反射候補の両方を提供するTURNサーバーによって学習できます。 | |
| Peer Reflexive Candidate：IPアドレスとポートが、NATを介してピアにSTUNバインディング要求を送信したときに、NATによってエージェントに割り当てられたバインディングである候補。 | |
| リレー候補：ホスト候補からTURNサーバーにTURN割り当て要求を送信することによって取得された候補。リレーされた候補者はTURNサーバーに常駐し、TURNサーバーはエージェントに向けてパケットをリレーします。 | |
| ベース：サーバーの再帰候補のベースは、それが派生したホスト候補です。ホスト候補者は、その候補者自身に等しいベースを持つとも言われます。同様に、中継された候補者のベースはその候補者自身です。 | |
| Foundation：同じタイプ、ベースIPアドレス、プロトコル（UDP、TCPなど）、およびSTUNまたはTURNサーバーを持つ2つの候補に対して同じである任意の文字列。これらのいずれかが異なる場合、基盤は異なります。同じ基礎ペアを持つ2つの候補ペアは、同様のネットワーク特性を持つ可能性があります。基礎は、凍結アルゴリズムで使用されます。 | |
| ローカル候補者：エージェントが取得し、送信したオファーまたは回答に含めた候補者。 | |
| リモート候補：エージェントがピアからオファーまたはアンサーで受け取った候補。 | |
| デフォルトの宛先/候補：メディアストリームのコンポーネントのデフォルトの宛先は、ICEに対応していないエージェントが使用するトランスポートアドレスです。RTPコンポーネントの場合、デフォルトのIPアドレスはSDPのc行にあり、ポートはm行にあります。RTCPコンポーネントの場合、存在する場合はrtcp属性にあり、存在しない場合、IPアドレスはc行にあり、1にポートを加えたものはm行にあります。コンポーネントのデフォルトの候補は、トランスポートアドレスがそのコンポーネントのデフォルトの宛先と一致するものです。 | |
| 候補ペア：ローカル候補とリモート候補を含むペア。 | |
| チェック、接続性チェック、STUNチェック：接続性を検証するためのSTUNバインディング要求トランザクション。候補ペアのローカル候補からリモート候補にチェックが送信されます。 | |
| チェックリスト：エージェントがチェックを生成するために使用する順序付けられた候補ペアのセット。 | |
| 通常のチェック：定期的に起動し、チェックを送信するように指示するタイマーの結果としてエージェントによって生成される接続性チェック。 | |
| トリガーチェック：ピアからの接続チェックの受信の結果として生成された接続チェック。 | |
| 有効リスト：成功したSTUNトランザクションによって検証されたメディアストリームの候補ペアの順序付きセット。 | |
| 完全：この仕様で定義されている機能の完全なセットを実行するICE実装。 | |
| Lite：特定の機能を省略したICE実装。ICEの利点を十分に活用できるピア実装に必要なだけ実装します。Liteの実装では、ステートマシンは保持されず、接続性チェックは生成されません。 | |
| 制御エージェント：候補ペアの最終選択を選択し、必要に応じてSTUNおよび更新されたオファーを介してそれらを通知するICEエージェント。どのセッションでも、1人のエージェントが常に制御しています。もう1つは管理対象エージェントです。 | |
| 制御エージェント：制御エージェントが候補ペアの最終選択を選択するのを待つICEエージェント。 | |
| 通常のノミネーション：1つのSTUN要求でペアを検証することによりメディアトラフィックの有効な候補ペアを選択し、その後、ノミネーションを示すフラグを付けて2番目のSTUN要求を送信することにより選択するプロセス。 | |
| アグレッシブノミネート：有効な候補ペアを生成する最初の候補がメディアに使用されるように、すべてのSTUN要求にフラグを含めることにより、メディアトラフィックの有効な候補ペアを選択するプロセス。 | |
| 指定：有効な候補ペアに指定フラグが設定されている場合、メディアの送受信用にICEによって選択される可能性があることを意味します。 | |
| 選択されたペア、選択された候補：メディアの送受信のためにICEによって選択された候補ペアは選択されたペアと呼ばれ、その候補のそれぞれは選択された候補と呼ばれます。 | |
| 4.初期オファーの送信 | |
| オファー/アンサー交換で初期オファーを送信するには、エージェントは（1）候補を収集し、（2）優先順位を付け、（3）冗長な候補を排除し、（4）デフォルトの候補を選択してから、（5）公式化し、 SDPオファーを送信します。これらの5つの手順の最後を除くすべては、完全実装と簡易実装で異なります。 | |
| 4.1。完全な実装要件 | |
| 4.1.1。候補者の収集 | |
| エージェントは、コミュニケーションが差し迫っていると考えたときに候補者を集めます。オファー側は、ユーザーインターフェイスのキューに基づいて、またはセッションを開始する明示的な要求に基づいてこれを行うことができます。すべての候補者 | |
| トランスポートアドレスです。タイプとベースもあります。この仕様では、ホスト候補、サーバー反射候補、ピア反射候補、およびリレー候補の4つのタイプが定義および収集されます。サーバーの再帰候補はSTUNまたはTURNを使用して収集され、中継された候補はTURNを介して取得されます。ピア反射候補は、接続性チェックの結果として、ICEの後期段階で取得されます。候補のベースは、その候補を使用するときにエージェントが送信する必要がある候補です。 | |
| 4.1.1.1。ホスト候補者 | |
| 最初のステップは、ホスト候補を収集することです。ホスト候補は、ホスト上のインターフェイス（VPNインターフェイスを含む物理または仮想）に接続されたIPアドレスのポート（通常は一時）にバインドすることによって取得されます。 | |
| エージェントが使用する各UDPメディアストリームについて、エージェントは、ホストが持つ各IPアドレスのメディアストリームの各コンポーネントの候補を取得する必要があります。特定のIPアドレスのUDPポートにバインドすることにより、各候補を取得します。ホスト候補（および実際にはすべての候補）は、常に候補である特定のコンポーネントに関連付けられています。各コンポーネントには、コンポーネントIDと呼ばれるIDが割り当てられています。RTPベースのメディアストリームの場合、RTP自体のコンポーネントIDは1、RTCPのコンポーネントIDは2です。エージェントがRTCPを使用している場合、その候補を取得する必要があります。エージェントがRTPとRTCPの両方を使用している場合、エージェントがK個のIPアドレスを持っていると、2 * K個のホスト候補になります。 | |
| 各ホスト候補のベースは、候補自体に設定されます。 | |
| 4.1.1.2。サーバーの再帰候補およびリレー候補 | |
| エージェントは、リレーされた候補を取得する必要があり（SHOULD）、サーバーの再帰候補を取得する必要があります（SHOULD）。これらの要件は、プロバイダーのバリエーションに対応できるようにする必要があります。STUNおよびTURNサーバーの使用は、エージェントがパブリックインターネットまたはクローズドネットワーク外のエンドポイントに接続されないクローズドネットワークでは不要な場合があります。そのような場合、デュアルスタックまたはマルチホームのエージェントに完全な実装を使用して、ホスト候補を選択します。TURNサーバーの使用は高価であり、ICEが使用されている場合、両方のエンドポイントがアドレスとポートに依存するマッピングを実行するNATの背後にある場合にのみ使用されます。そのため、一部の展開では、このユースケースを限界と見なし、TURNサーバーを使用しないことを選択する場合があります。エージェントがサーバーの再帰候補またはリレー候補を収集しない場合、 | |
| エージェントがリレー候補とサーバー再帰候補の両方を収集している場合、TURNサーバーを使用します。サーバーの再帰候補のみを収集する場合は、STUNサーバーを使用します。 | |
| 次に、エージェントは、各ホスト候補を、それが構成されている、または何らかの手段で発見したSTUNまたはTURNサーバーとペアにします。STUNまたはTURNサーバーが構成されている場合は、ドメイン名を構成し、[RFC5389]のDNS手順（「stun」サービスでSRVレコードを使用）を使用してSTUNサーバーとDNS手順を検出することをお勧めします[RFC5766]の（「turn」サービスでSRVレコードを使用して）TURNサーバーを検出するために使用されます。 | |
| この仕様では、単一のSTUNまたはTURNサーバーの使用のみを考慮しています。その単一のSTUNまたはTURNサーバーに複数の選択肢がある場合（たとえば、それらがDNSレコードを介して学習され、複数の結果が返される場合）、エージェントはすべてのIPアドレスに基づいて単一のSTUNまたはTURNサーバーを使用する必要があります（SHOULD）特定のセッションの候補。これにより、ICEのパフォーマンスが向上します。結果は、STUNまたはTURNサーバーとホスト候補のペアのセットです。次に、エージェントは1つのペアを選択し、そのホスト候補からBindingまたはAllocate要求をサーバーに送信します。STUNサーバーへのバインド要求は認証されず、応答内のALTERNATE-SERVER属性は無視されます。エージェントは、[RFC5389]で定義されたBinding要求の後方互換性モードをサポートする必要があります。 | |
| その後Taミリ秒ごとに、エージェントは別の新しいSTUNまたはTURNトランザクションを生成できます。このトランザクションは、回復可能なエラー（認証の失敗など）で失敗した以前のトランザクションの再試行、または新しいホスト候補とSTUNまたはTURNサーバーのペアのトランザクションのいずれかです。エージェントは、Taミリ秒ごとに1回よりも頻繁にトランザクションを生成すべきではありません。TaおよびSTUN再送信タイマー、RTOの設定方法に関するガイダンスについては、セクション16を参照してください。 | |
| エージェントは、BindingまたはAllocate応答を受け取ります。Allocate応答が成功すると、エージェントにサーバー反射候補（マップされたアドレスから取得）と、XOR-RELAYED-ADDRESS属性の中継候補が提供されます。サーバーがそれを満たすためのリソースが不足しているためにAllocateリクエストが拒否された場合、エージェントは代わりにBindingリクエストを送信してサーバー反射候補を取得する必要があります。バインディング応答は、エージェントにサーバー反射候補のみを提供します（マップされたアドレスからも取得されます）。サーバー反射候補のベースは、割り当て要求またはバインディング要求が送信されたホスト候補です。リレーされた候補者のベースは、その候補者自身です。リレーされた候補者 | |
| ホスト候補（まれなケースで発生する可能性がある）と同一である場合、リレーされた候補は破棄されなければなりません。 | |
| 4.1.1.3。コンピューティング基盤 | |
| 最後に、エージェントは各候補者に基礎を割り当てます。基盤は、セッション内でスコープされる識別子です。次のすべてに該当する場合、2つの候補者は同じ基盤IDを持っている必要があります。 | |
| oそれらは同じタイプ（ホスト、リレー、サーバー反射、またはピア反射）です。 | |
| oベースのIPアドレスは同じです（ポートは異なる場合があります）。 | |
| o再帰およびリレー候補の場合、候補を取得するために使用されるSTUNまたはTURNサーバーは同じIPアドレスを持ちます。 | |
| o同じトランスポートプロトコル（TCP、UDPなど）を使用して取得された。 | |
| 同様に、タイプが異なる場合、ベースのIPアドレスが異なる場合、取得に使用されるSTUNサーバーまたはTURNサーバーのIPアドレスが異なる場合、またはトランスポートプロトコルが異なる場合、2つの候補は異なる基盤を持たなければなりません。 | |
| 4.1.1.4。候補者を生かしておく | |
| サーバーの再帰候補および中継候補が割り当てられたら、セクション8.3で説明されているように、ICE処理が完了するまで生存し続ける必要があります。バインディングリクエストを介して学習されたサーバーの再帰候補の場合、サーバーへの追加のバインディングリクエストによってバインディングを維持する必要があります。[RFC5766]で説明されているように、割り当ての更新は更新トランザクションを使用して行われます。更新要求は、サーバーの再帰候補も更新します。 | |
| 4.1.2。候補者の優先順位付け | |
| 優先順位付けプロセスにより、各候補者に優先順位が割り当てられます。メディアストリームの各候補には、1〜（2 ** 31-1）の間の正の整数でなければならない一意の優先度がなければなりません。この優先順位は、接続性チェックの順序と候補者の相対的な優先順位を決定するためにICEによって使用されます。 | |
| エージェントは、セクション4.1.2.1の式を使用してこの優先度を計算し、セクション4.1.2.2のガイドラインを使用してパラメータを選択する必要があります。エージェントが異なる式を使用することを選択した場合、両方のエージェントがチェックで調整されないため、ICEの収束に時間がかかります。4.1.2.1。推奨フォーミュラ | |
| 式を使用する場合、エージェントは各タイプの候補（サーバー反射型、ピア反射型、リレー型、およびホスト）の優先順位を決定することによって優先順位を計算し、エージェントがマルチホームの場合、そのIPアドレスの優先順位を選択します。次に、これら2つの設定を組み合わせて、候補の優先順位を計算します。その優先順位は、次の式を使用して計算されます。 | |
| 優先度=（2 ^ 24）*（タイプ設定）+（2 ^ 8）*（ローカル設定）+（2 ^ 0）*（256-コンポーネントID） | |
| タイプ設定は、0から126までの整数でなければならず（MUST）、候補のタイプ（タイプはローカル、サーバー反射、ピア反射、およびリレー）の設定を表します。126は最高の優先度であり、0は最低の優先度です。値を0に設定すると、このタイプの候補は最後の手段としてのみ使用されます。タイプ設定は、同じタイプのすべての候補に対して同一である必要があり、異なるタイプの候補に対して異なる必要があります。ピアの再帰候補のタイプの優先度は、サーバーの再帰候補のタイプの優先度よりも高くなければなりません。セクション4.1.1の手順に基づいて収集された候補者は、ピア反射候補者になることはありません。これらのタイプの候補は、ICEによって実行される接続性チェックから学習されます。 | |
| ローカルプリファレンスは、0〜65535の整数でなければなりません。エージェントがマルチホームの場合、候補が取得された特定のIPアドレスの優先順位を表します。65535は最高の優先順位を表し、ゼロは最低の優先順位を表します。IPアドレスが1つしかない場合、この値は65535に設定する必要があります。より一般的には、同じタイプを持つ特定のメディアストリームの特定のコンポーネントに複数の候補がある場合、ローカルプリファレンスはそれぞれに対して一意でなければなりません。この仕様では、これはマルチホームホストでのみ発生します。ホストがデュアルスタックであるためにマルチホームである場合、ローカルプリファレンスは、RFC 3484 [RFC3484]で説明されているIPアドレスの優先順位値と等しく設定する必要があります。 | |
| コンポーネントIDは候補のコンポーネントIDであり、1〜256の範囲である必要があります。 | |
| 4.1.2.2。タイプとローカルプリファレンスを選択するためのガイドライン | |
| タイプとローカルプリファレンス値の選択基準の1つは、TURNサーバー、VPNサーバー、NATなどのメディア仲介の使用です。メディアを介して、メディアがそこに送信される場合 | |
| 候補者は、最初にメディア仲介者を通過してから受信します。リレーされた候補者は、メディア仲介者が関与する候補者の一種です。もう1つは、VPNインターフェイスから取得したホスト候補です。メディアがメディア仲介者を通過するとき、送信と受信の間の待ち時間が長くなる可能性があります。ルーターホップが追加されるため、パケット損失が増加する可能性があります。メディアはプロバイダーによって実行されるメディア仲介者にルーティングされ、またメディアアウトバックされるため、サービスの提供コストが増加する可能性があります。これらの懸念が重要な場合、リレーされた候補のタイプの優先順位は、ホストの候補よりも低くする必要があります。RECOMMENDED値は、ホスト候補の場合は126、サーバー反射候補の場合は100、ピア反射候補の場合は110、リレー候補の場合は0です。さらに、 | |
| プリファレンスの選択のもう1つの基準は、IPアドレスファミリです。ICEは、IPv4とIPv6の両方で機能します。そのため、デュアルスタックホストがIPv6よりも接続性を優先できる移行メカニズムを提供しますが、v6ネットワークが切断された場合（たとえば、6to4リレーの障害など）にIPv4にフォールバックできます[RFC3056]。また、ネイティブIPv6アドレスと6to4アドレスの両方を持つホストにも役立ちます。このような場合、より高いローカルプリファレンスをv6アドレスに割り当て、6to4アドレス、v4アドレスの順に割り当てることができます。これにより、サイトはネイティブv6アドレスをすぐに取得して使用を開始できますが、ネイティブv6接続をまだ持っていない他のサイトのエージェントと通信するときは6to4アドレスにフォールバックします。 | |
| 設定を選択する別の基準はセキュリティです。ユーザーが在宅勤務者であり、したがって企業ネットワークとローカルホームネットワークに接続している場合、ユーザーは、企業内で通信する際に音声トラフィックを企業ネットワーク上に保持するためにVPN経由でルーティングすることを好む場合がありますが、企業外のユーザーと通信するときのローカルネットワーク。このような場合、VPNアドレスは他のアドレスよりもローカルの優先度が高くなります。 | |
| プリファレンスを選択するためのもう1つの基準は、トポロジ認識です。これは、仲介者を利用する候補者にとって最も便利です。これらの場合、エージェントが自身の仲介者のトポロジー的近接性に関する事前設定済みまたは動的な発見を持っている場合、それを使用して、より近い仲介者から取得した候補により高いローカルプリファレンスを割り当てることができます。 | |
| 4.1.3。冗長候補者の排除 | |
| 次に、エージェントは冗長な候補を排除します。候補は、そのトランスポートアドレスが別の候補と等しく、そのベースが他の候補のベースと等しい場合、冗長です。2つの候補は同じトランスポートアドレスを持つことができますが、異なるベースを持つことができ、これらは冗長とは見なされないことに注意してください。多くの場合、エージェントがNATの背後にない場合、サーバーの再帰候補とホスト候補は冗長になります。エージェントは、優先度の低い冗長な候補を排除すべきである。 | |
| 4.1.4。デフォルト候補の選択 | |
| 候補は、非ICEピアからのメディアのターゲットになる場合、デフォルトであると言われます。そのターゲットはDEFAULT DESTINATIONと呼ばれます。ICE対応ピアと通信するときにICEアルゴリズムによってデフォルトの候補が選択されない場合、ICE処理が完了した後、メディアのデフォルトの宛先が一致するようにSDPを「修正」するために、更新されたオファー/アンサーが必要になりますICEが選択した候補。ICEがデフォルトの候補者を選択した場合、更新されたオファー/アンサーは必要ありません。 | |
| エージェントは、デフォルトとして、使用中の各メディアストリームの各コンポーネントに1つずつ、候補のセットを選択する必要があります。メディアストリームは、RFC 3264でメディアストリームを拒否するために使用されるゼロのポートがない場合、使用中です。したがって、メディアストリームは、a = inactive [RFC4566]としてマークされているか、帯域幅値がゼロであっても使用中です。 | |
| デフォルトの候補は、連絡されているピアと連携する可能性に基づいて選択されることが推奨されます。デフォルトの候補は、リレー候補（リレー候補が利用可能な場合）、サーバー反射候補（サーバー反射候補が利用可能な場合）、最後にホスト候補であることが推奨されます。 | |
| 4.2。Liteの実装要件 | |
| Lite実装は、ホスト候補のみを利用します。ライトインプリメンテーションでは、各メディアストリームの各コンポーネントに、ゼロまたは1つのIPv4候補を割り当てる必要があります。0個以上のIPv6候補を割り当てることができますが、ホストが使用する各IPv6アドレスごとに1個のみを割り当てることができます。各メディアストリームのコンポーネントごとにIPv4候補は1つしか存在できないため、エージェントに複数のIPv4アドレスがある場合、候補を割り当てるために1つを選択する必要があります。ホストがデュアルスタックの場合、1つのIPv4候補と1つのグローバルIPv6アドレスを割り当てることをお勧めします。ライトの実装では、ICEを使用して候補の中から動的に選択することはできません。したがって、特定のスコープからの複数の候補を含めることは推奨されません。なぜなら、接続チェックだけが、あるアドレスを使用するか他のアドレスを使用するかを真に決定できるからです。 | |
| 各コンポーネントには、コンポーネントIDと呼ばれるIDが割り当てられています。RTPベースのメディアストリームの場合、RTP自体のコンポーネントIDは1、RTCPのコンポーネントIDは2です。エージェントがRTCPを使用している場合、その候補を取得する必要があります。 | |
| 各候補者には基礎が割り当てられます。基盤は、異なるIPアドレスから割り当てられた2つの候補に対して異なる必要があり、それ以外は同じでなければなりません。IPアドレスごとに増分する単純な整数で十分です。さらに、各候補には、同じメディアストリームのすべての候補の中で一意の優先順位を割り当てる必要があります。この優先度は次の値と同じである必要があります。 | |
| priority =（2 ^ 24）*（126）+（2 ^ 8）*（IP precedence）+（2 ^ 0）*（256-コンポーネントID） | |
| ホストがv4のみの場合、IP優先順位を65535に設定する必要があります。ホストがv6またはデュアルスタックの場合、IP優先順位はRFC 3484 [RFC3484]で説明されているIPアドレスの優先順位値である必要があります。 | |
| 次に、エージェントは各メディアストリームの各コンポーネントのデフォルト候補を選択します。ホストがIPv4のみの場合、各メディアストリームの各コンポーネントに対して1つの候補しか存在しないため、その候補がデフォルトになります。ホストがIPv6またはデュアルスタックの場合、デフォルトの選択はローカルポリシーの問題です。このデフォルトは、ピアで使用される可能性が最も高い候補になるように選択する必要があります。IPv6のみのホストの場合、これは通常、グローバルスコープのIPv6アドレスになります。デュアルスタックホストの場合、IPv4アドレスが推奨されます。 | |
| 4.3。SDPのエンコード | |
| SDPをエンコードするプロセスは、フル実装とライト実装で同一です。 | |
| エージェントには、使用する各メディアストリームにm行が含まれます。SDPのメディアストリームの順序は、ICEに関連しています。ICEは、最初のm行の接続性チェックを最初に実行し、その結果、メディアは最初にそのストリームに流れることができます。エージェントは、最も重要なメディアストリームがある場合は、SDPに最初に配置する必要があります。 | |
| 特定のメディアストリームの候補ごとに候補属性があります。セクション15は、この属性を構築するための詳細な規則を提供します。この属性には、候補のIPアドレス、ポート、およびトランスポートプロトコルが含まれ、さらに、ICEが機能するためにピアに通知する必要があるプロパティ（優先度、基盤、コンポーネントID）が含まれます。候補属性には、診断やその他の機能に役立つ候補に関する情報も含まれます。その種類と関連するトランスポートアドレスです。 | |
| エージェント間のSTUN接続性チェックは、STUN [RFC5389]に定義された短期的な認証メカニズムを使用して認証されます。このメカニズムは、クライアントとサーバー間のプロトコルマシンを介して交換されるユーザー名とパスワードに依存しています。ICEでは、オファー/アンサー交換がそれらの交換に使用されます。このクレデンシャルのユーザー名部分は、各エージェントからのユーザー名フラグメントをコロンで区切って連結することにより形成されます。また、各エージェントは、受信したリクエストのメッセージの整合性を計算するために使用されるパスワードを提供します。ユーザー名のフラグメントとパスワードは、それぞれice-ufrag属性とice-pwd属性で交換されます。セキュリティを提供することに加えて、ユーザー名は曖昧さを取り除き、チェックとメディアストリームの相関を提供します。動機については、付録B.4を参照してください。 | |
| エージェントがライト実装の場合、SDPに「a = ice-lite」セッションレベル属性を含める必要があります。エージェントが完全な実装である場合、この属性を含めてはなりません。 | |
| デフォルトの候補は、メディアのデフォルトの宛先としてSDPに追加されます。RTPに基づくストリームの場合、これは、RTP候補のIPアドレスとポートをそれぞれc行とm行に配置することにより行われます。エージェントがRTCPを利用している場合、RFC 3605 [RFC3605]で定義されているa = rtcp属性を使用してRTCP候補をエンコードしなければなりません。RTCPが使用されていない場合、エージェントは、RFC 3556 [RFC3556]で定義されているように、b = RS：0およびb = RR：0を使用していることを通知する必要があります。 | |
| 非ICEピアと通信するときにメディアのデフォルトの宛先となるトランスポートアドレスも、1つ以上のa = candidate行の候補として存在しなければなりません。 | |
| ICEは、そのエージェントが使用するICE拡張機能を識別する一連のトークンをオファーまたはアンサーに含めることにより、拡張性を提供します。エージェントがICE拡張をサポートする場合、ice-options属性にその拡張に対して定義されたトークンを含める必要があります。 | |
| 以下は、ICE属性（読みやすくするために折り返された行）を含むSDPメッセージの例です。 | |
| v = 0 o = jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s = c = IN IP4 192.0.2.3 t = 0 0 a = ice-pwd：asd88fgpdd777uzjYhagZg a = ice-ufrag：8hhY m = audio 45664 RTP / AVP 0 b = RS：0 b = RR：0 a = rtpmap：0 PCMU / 8000 a = candidate：1 1 UDP 2130706431 10.0.1.1 8998 typ host a = candidate：2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 | |
| エージェントがオファーまたはその回答を送信すると、そのエージェントは、各候補でSTUNパケットとメディアパケットの両方を受信する準備をする必要があります。セクション11.1で説明したように、オファーまたはアンサーのメディアのデフォルトの宛先として表示される前に、メディアパケットを候補に送信できます。 | |
| 5.初期オファーの受け取り | |
| エージェントは初期オファーを受け取ると、オファー側がICEをサポートしているかどうかを確認し、独自の役割を決定し、候補者を収集し、優先順位を付け、デフォルトの候補者を選択し、回答をエンコードして送信します。完全な実装では、チェックリストを形成して接続を開始しますチェック。 | |
| 5.1。ICEサポートの確認 | |
| エージェントは、受信したSDPの各メディアストリームについて、そのメディアストリームの各コンポーネントのデフォルトの宛先が候補属性に表示される場合、この仕様で定義されているICE手順を続行します。たとえば、RTPの場合、c行とm行のIPアドレスとポートはそれぞれ候補属性に表示され、rtcp属性の値は候補属性に表示されます。 | |
| この条件が満たされない場合、エージェントは、次の例外を除き、この仕様の残りの部分で説明するICEメカニズムを使用せずに、通常のRFC 3264手順に基づいてSDPを処理する必要があります。 | |
| 1.エージェントは、すべてのエージェントのキープアライブ手順を説明するセクション10の規則に従う必要があります。 | |
| 2. a = candidate属性があり、メディアストリームのデフォルトの宛先に一致するものがなかったためにエージェントがICEを処理しない場合、エージェントはその応答にa = ice-ミスマッチ属性を含める必要があります。 | |
| 3.デフォルトの候補がTURNサーバーを介して学習された候補を中継した場合、エージェントは受信したSDPのピアから学習したIPアドレスの許可をTURNサーバーで作成する必要があります。これを行わないと、ピアからのメディアストリームの初期パケットが失われる可能性があります。 | |
| 5.2。役割の決定 | |
| セッションごとに、各エージェントが役割を担います。制御と制御の2つの役割があります。制御エージェントは、通信に使用される最終的な候補ペアの選択を担当します。フルエージェントの場合、これは、各メディアストリームに対してICEが使用できる候補ペアを指定し、必要に応じてICEの選択に基づいて更新されたオファーを生成することを意味します。ライト実装の場合、制御エージェントになるということは、オファーとアンサーのペアに基づいて候補ペアを選択し（IPv4の場合、ペアは1つだけです）、必要に応じてその選択を反映する更新されたオファーを生成することです（ IPv4のみのホストには必要ありません）。制御されたエージェントは、各メディアストリームに使用する候補のペアを通知され、この情報を通知する更新されたオファーを生成しません。 | |
| ロールと動作への影響を決定するためのルールは次のとおりです。 | |
| 両方のエージェントがいっぱいです：ICE処理を開始したオファーを生成したエージェントが制御の役割を引き受け、他のエージェントが制御の役割を引き受けなければなりません。両方のエージェントがチェックリストを作成し、ICEステートマシンを実行し、接続性チェックを生成します。制御エージェントは、セクション8.1のロジックを実行して、ICEによって選択されるペアを指定し、セクション8.1.2で説明したように両方のエージェントがICEを終了します。付録B.11に記載されている異常なケースでは、両方のエージェントが自分が制御されている、または制御していると誤って信じることがあります。これを解決するために、各エージェントは、0と（2 ** 64）-1（つまり、64ビットの正の整数）の間に均一に分布するタイブレーカーと呼ばれる乱数を選択する必要があります。この番号は、セクション7.1.2.2で説明されているように、このケースを検出および修復するための接続チェックで使用されます。 | |
| 1人のエージェントがフル、1人のライト：フルエージェントが制御の役割を引き受けなければならず、ライトエージェントが制御の役割を引き受けなければなりません。完全なエージェントはチェックリストを作成し、ICEステートマシンを実行し、接続性チェックを生成します。そのエージェントは、セクション8.1のロジックを実行してICEによって選択されるペアを指定し、セクション8.1.2のロジックを使用してICEを終了します。ライトの実装は、接続性チェックをリッスンし、それらを受信して応答し、セクション8.2で説明されているようにICEを終了します。ライトの実装では、各メディアストリームのICE処理の状態は実行中と見なされ、ICE全体の状態は実行中です。 | |
| Both lite：ICE処理を開始したオファーを生成したエージェントは制御の役割を引き受けなければならず、他のエージェントは制御の役割を引き受けなければなりません。この場合、接続チェックは送信されません。むしろ、オファー/アンサー交換が完了すると、各エージェントは接続チェックなしでセクション8で説明されている処理を実行します。両方のエージェントが、自分が管理されている、または管理していると考える可能性があります。後者の場合、オファー/アンサー交換を伝送するシグナリングプロトコルのグレア検出機能によって競合が解決されます。各メディアストリームのICE処理の状態は実行中と見なされ、ICE全体の状態は実行中です。 | |
| セッションの役割が決定されると、ICEを再起動しない限り持続します。ICEの再起動（9.1節）により、役割とタイブレーカーが新たに選択されます。 | |
| 5.3。候補者の収集 | |
| 回答者で候補者を収集するプロセスは、完全な実装についてはセクション4.1.1で、ライト実装についてはセクション4.2で説明した提供者のプロセスと同じです。このプロセスは、ユーザーに警告する前に、オファーを受信するとすぐに開始することをお勧めします。このような収集は、エージェントが開始されると開始する場合があります。 | |
| 5.4。候補者の優先順位付け | |
| 回答者で候補者に優先順位を付けるプロセスは、完全な実装についてはセクション4.1.2、ライト実装についてはセクション4.2で説明するように、提供者が従うプロセスと同じです。 | |
| 5.5。デフォルト候補の選択 | |
| 回答者でデフォルトの候補を選択するプロセスは、完全な実装についてはセクション4.1.4、ライト実装についてはセクション4.2で説明されているように、提供者が従うプロセスと同じです。 | |
| 5.6。SDPのエンコード | |
| 回答者でSDPをエンコードするプロセスは、セクション4.3で説明されているように、完全実装と簡易実装の両方で提供者が従うプロセスと同じです。 | |
| 5.7。チェックリストの作成 | |
| チェックリストの作成は、完全な実装によってのみ行われます。Lite実装では、このセクションで定義されている手順をスキップする必要があります。 | |
| オファー/アンサー交換から生じる使用中のメディアストリームごとに1つのチェックリストがあります。メディアストリームのチェックリストを作成するために、エージェントは候補ペアを形成し、候補ペアの優先度を計算し、優先度でペアを並べ替え、それらをプルーニングし、状態を設定します。このセクションでは、これらの手順について説明します。 | |
| 5.7.1。候補ペアの形成 | |
| まず、エージェントはメディアストリームの各候補（LOCAL CANDIDATESと呼ばれる）を取得し、そのメディアストリームのピア（REMOTE CANDIDATESと呼ばれる）から受信した候補とペアにします。セクション18.5.2で説明されている攻撃を防ぐために、エージェントはオファーまたはアンサーで受け入れる候補者の数を制限できます。2つの候補が同じコンポーネントIDを持ち、同じIPアドレスバージョンを持っている場合に限り、ローカル候補はリモート候補とペアになります。ローカル候補者の一部がリモート候補者とペアリングされず、リモート候補者の一部がローカル候補者とペアリングされない可能性があります。これは、1つのエージェントがメディアストリームのすべてのコンポーネントの候補を含まない場合に発生する可能性があります。これが発生した場合、 | |
| RTPの場合、一方のエージェントがRTCPの候補を提供し、もう一方が提供しない場合、これが発生します。別の例として、提供者は同じポートでRTPとRTCPを多重化し、SDP属性[RFC5761]を通じてSDPでそれを行うことができることを通知できます。ただし、オファー側はアンサー側がそのような多重化を実行できるかどうかを知らないため、オファー側はRTPとRTCPの候補を別々のポートに含め、メディアストリームごとに2つのコンポーネントを提供します。回答者がそのような多重化を実行できる場合、各RTP / RTCPマルチプレクサの候補ごとに1つのコンポーネントのみが含まれます。ICEは、この候補のコンポーネントが1つだけであるかのように振る舞うことになります。 | |
| ローカル候補とリモート候補の両方が特定のコンポーネントのデフォルト候補である候補ペアは、当然のことながら、そのコンポーネントのデフォルト候補ペアと呼ばれます。これは、両方のエージェントがICEに対応していない場合にメディアを送信するために使用されるペアです。 | |
| 理解を助けるために、図6は、いくつかの重要な概念（トランスポートアドレス、候補、候補ペア、およびチェックリスト）の関係を示しています。また、候補と候補ペアの主な特性を示しています。 | |
| + ------------------------------------------ + | | | + --------------------- + | | | + ---- + + ---- + + ---- + | +タイプ| | || IP | |ポート| |トラン| | +優先度| | ||アドレス| | | | | | +財団| | | + ---- + + ---- + + ---- + | + ComponentiD | | | 輸送| + RelatedAddr | | | 加算器| | | + --------------------- + +ベース| | 候補者| + ------------------------------------------ + * * * *** ********************************** * * + ------------- ------------------ +。| | | ローカルリモート| | + ---- + + ---- + + default？| | | Cand | | Cand | +有効？| | + ---- + + ---- + +ノミネート？| | +州| | | | | | 候補ペア| + ------------------------------- + * * * ************ * * + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + + ------------------ + | 候補ペア| + ------------------ + | |
| チェックリスト | |
| 図6：チェックリストの概念図 | |
| 5.7.2。ペアの優先度と順序ペアの計算 | |
| ペアが形成されると、候補ペアの優先度が計算されます。Gを、制御エージェントによって提供される候補の優先順位とします。制御されたエージェントによって提供される候補の優先度をDとします。ペアの優先度は次のように計算されます。 | |
| ペアの優先度= 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。ペアの剪定 | |
| このソートされた候補ペアのリストは、実行される接続性チェックのシーケンスを決定するために使用されます。各チェックには、ローカル候補からリモート候補へのリクエストの送信が含まれます。エージェントは再帰候補から直接リクエストを送信することはできず、ベースからのみリクエストを送信できるため、次にエージェントは候補ペアのソート済みリストを調べます。ローカル候補がサーバー反射型である各ペアでは、サーバー反射型候補をそのベースに置き換えなければなりません。これが完了すると、エージェントはリストを削除する必要があります。これは、ローカル候補とリモート候補が優先順位リストの上位にあるペアのローカル候補とリモート候補と同一である場合、ペアを削除することによって行われます。結果は、そのメディアストリームのチェックリストと呼ばれる順序付けられた候補ペアのシーケンスです。 | |
| さらに、セクション18.5.2で説明されている攻撃を制限するために、エージェントは、エージェントがすべてのチェックリストで実行する接続チェックの合計数を特定の値に制限しなければならず、この値は設定可能でなければなりません。デフォルトの100は推奨です。この制限は、優先順位の低い候補のペアを100未満になるまで破棄することで実施されます。可能な場合は、実際の展開構成で見られる可能性のあるチェックの最大数に設定して、低い値を使用することをお勧めします。構成の要件は、展開後に問題があることが判明した場合に、フィールドでこの値を修正するためのツールを提供することを目的としています。 | |
| 5.7.4。コンピューティング状態 | |
| チェックリストの各候補ペアには、基礎と状態があります。基盤は、ペアのローカル候補とリモート候補の基盤の組み合わせです。各メディアストリームのチェックリストが計算されると、状態が割り当てられます。状態が取りうる5つの潜在的な値があります。待機中：このペアに対してチェックは実行されておらず、チェックリストで最も優先度の高い待機ペアになるとすぐに実行できます。 | |
| 進行中：このペアに対してチェックが送信されましたが、トランザクションは進行中です。 | |
| 成功：このペアのチェックはすでに完了しており、成功した結果が生成されました。 | |
| 失敗：このペアのチェックはすでに完了しており、応答を生成しないか、回復不能な失敗応答を生成しました。 | |
| Frozen：このペアのチェックは実行されておらず、他のチェックが成功するまで実行できず、このペアはフリーズを解除して待機状態に移行できます。 | |
| ICEが実行されると、図7に示すように、ペアは状態間を移動します。 | |
| + ----------- + | | | | | 冷凍| | | | | + ----------- + | |フリーズ解除| V + ----------- + + ----------- + | | | | | | 実行する| | | 待機中| --------> |進行中| | | | | | | | | + ----------- + + ----------- + / | // | // | // | / | // | 失敗// |成功// | / | // | // | // | VV + ----------- + + ----------- + | | | | | | | | | 失敗しました| | 成功しました| | | | | | | | | + ----------- + + ----------- + | |
| 図7：ペア状態FSM | |
| チェックリストの各ペアの初期状態は、次の一連の手順を実行して計算されます。 | |
| 1.エージェントは、各チェックリストのすべてのペアをフローズン状態に設定します。 | |
| 2.エージェントは、最初のメディアストリームのチェックリストを調べます（メディアストリームは、SDPのオファーとアンサーの最初のm行で記述されている場合、最初のメディアストリームです）。そのメディアストリームの場合： | |
| *同じ基盤を持つすべてのペアについて、最も低いコンポーネントIDを持つペアの状態を待機中に設定します。そのようなペアが複数ある場合、最も優先度の高いペアが使用されます。 | |
| チェックリストの1つにはいくつかのペアが待機状態にあり、他のチェックリストにはすべてのペアが凍結状態にあります。少なくとも1つのペアが待機中のチェックリストはアクティブなチェックリストと呼ばれ、すべてのペアが凍結されたチェックリストは凍結されたチェックリストと呼ばれます。 | |
| チェックリスト自体は状態に関連付けられ、そのメディアストリームのICEチェックの状態をキャプチャします。次の3つの状態があります。 | |
| 実行中：この状態では、このメディアストリームのICEチェックがまだ進行中です。 | |
| 完了：この状態では、ICEチェックにより、メディアストリームの各コンポーネントに対して指定されたペアが生成されています。その結果、ICEは成功し、メディアを送信できます。 | |
| 失敗：この状態では、このメディアストリームのICEチェックは正常に完了していません。 | |
| チェックリストがオファー/アンサー交換の結果として最初に構築されるとき、実行中状態になります。 | |
| すべてのメディアストリームでのICE処理にも状態が関連付けられています。この状態は、ICE処理の実行中は実行中に等しくなります。ICE処理が完了すると状態はCompletedになり、成功せずに失敗した場合はFailedになります。状態間を遷移するための規則を以下に説明します。 | |
| 5.8。スケジュールチェック | |
| チェックは完全な実装によってのみ生成されます。Lite実装では、このセクションで説明されている手順をスキップする必要があります。 | |
| エージェントは通常のチェックとトリガーされたチェックを実行します。両方のチェックの生成は、各メディアストリームに対して定期的に起動するタイマーによって管理されます。エージェントは、トリガーされたチェックキューと呼ばれるFIFOキューを保持します。このキューには、次に利用可能な機会にチェックが送信される候補ペアが含まれています。タイマーが作動すると、エージェントはトリガーされたチェックキューから一番上のペアを削除し、そのペアで接続チェックを実行し、候補ペアの状態を進行中に設定します。トリガーされたチェックキューにペアがない場合、通常のチェックが送信されます。 | |
| エージェントは、セクション5.7で説明されているようにチェックリストを計算すると、アクティブなチェックリストごとにタイマーを設定します。タイマーはTa * N秒ごとに起動します。Nはアクティブなチェックリストの数です（最初はアクティブなチェックリストは1つだけです）。実装は、これよりも少ない頻度でタイマーを設定できます。実装は、各メディアストリームで同時に起動しないように、これらのタイマーを広げるように注意する必要があります。Taおよび再送信タイマーRTOは、セクション16で説明されているように計算されます。Nを乗算すると、この集約チェックスループットをすべてのアクティブなチェックリスト間で分割できます。最初のタイマーはすぐに起動するため、エージェントはオファー/アンサー交換が行われた瞬間に接続性チェックを実行し、次にTa秒後に次のチェックが実行されます（アクティブなチェックリストが1つしかないため）。 | |
| タイマーが作動し、送信されるトリガーチェックがない場合、エージェントは次のように通常のチェックを選択する必要があります。 | |
| o待機状態にあるチェックリストで最も優先度の高いペアを見つけます。 | |
| oそのようなペアがある場合： | |
| *そのペアのローカル候補からそのペアのリモート候補にSTUNチェックを送信します。この目的のためにSTUN要求を形成する手順は、セクション7.1.2で説明されています。 | |
| *候補ペアの状態を進行中に設定します。 | |
| oそのようなペアがない場合： | |
| *凍結状態にあるチェックリストで最も優先度の高いペアを見つけます。 | |
| *そのようなペアがある場合： | |
| +ペアの凍結を解除します。 | |
| +そのペアのチェックを実行して、状態をIn-Progressに移行します。 | |
| *そのようなペアがない場合： | |
| +そのチェックリストのタイマーを終了します。 | |
| チェックのメッセージ整合性を計算するために、エージェントはピアからSDPから学習したリモートユーザー名フラグメントとパスワードを使用します。ローカルユーザー名のフラグメントは、エージェントが自身の候補として直接認識しています。 | |
| 6.初期回答の受領 | |
| このセクションでは、エージェントがピアから回答を受信する際に従う手順について説明します。ピアがICEをサポートしていることを確認し、その役割を決定し、完全な実装のためにチェックリストを作成し、通常のチェックの実行を開始します。 | |
| ICEをSIPで使用する場合、分岐によって単一のオファーが多数の回答を生成する場合があります。その場合、ICEは回答ごとに完全に並行して独立して進行し、オファーと各回答の組み合わせを、独自のペア、チェックリスト、状態などの独立したオファー/回答交換として扱います。1つのペアの処理が別のペアに影響を与える唯一のケースは、セクション8.3で後述する候補の解放です。 | |
| 6.1。ICEサポートの確認 | |
| 申出人のロジックは、SDPでa = ice-mismatch属性を生成しないという例外を除き、セクション5.1で説明した回答者のロジックと同じです。 | |
| 場合によっては、答えはメディアストリームのa = candidate属性を省略し、代わりにSDPの1つ以上のメディアストリームのa = ice-mismatch属性を含めることができます。これは、回答者がICEをサポートしているが、対応する候補属性を変更せずにメディアコンポーネントのデフォルトの宛先を変更したため、ICE処理がセッションに使用されなかったことを提供者に通知します。これが発生する可能性のあるケースについては、セクション18を参照してください。この仕様では、このような障害が発生した場合のエージェントの処理方法に関するガイダンスは提供されていません。 | |
| 6.2。役割の決定 | |
| 申出人は、セクション5.2で回答者について説明したのと同じ手順に従います。 | |
| 6.3。チェックリストの作成 | |
| チェックリストの形成は、完全な実装によってのみ実行されます。申出人は、セクション5.7で回答者について説明したのと同じ手順に従います。 | |
| 6.4。通常のチェックの実行 | |
| 通常のチェックは、完全な実装によってのみ実行されます。申出人は、セクション5.8で回答者について説明したのと同じ手順に従います。 | |
| 7.接続性チェックの実行 | |
| このセクションでは、接続チェックの実行方法について説明します。すべてのICE実装は、古い[RFC3489]とは対照的に、[RFC5389]に準拠する必要があります。ただし、完全な実装ではチェックの生成（STUNクライアントとして機能）と受信（STUNサーバーとしての機能）の両方が行われますが、ライト実装はチェックのみを受信するため、STUNサーバーとしてのみ機能します。 | |
| 7.1。STUNクライアントの手順 | |
| これらの手順では、通常のチェックであるかトリガーチェックであるかに関係なく、エージェントが接続チェックを送信する方法を定義します。これらの手順は、完全な実装にのみ適用されます。 | |
| 7.1.1。中継された候補者のアクセス許可の作成 | |
| リレーされたローカル候補を使用して接続性チェックが送信されている場合、以前に許可を作成していない場合、クライアントは最初に許可を作成する必要があります。TURNサーバーに、リモート候補のIPアドレスに対する特定のリレー候補の許可を作成するように指示した場合、以前に作成されていたはずです。許可を作成するために、エージェントは[RFC5766]で定義された手順に従います。リモート候補者のIPアドレスに対して許可を作成する必要があります。エージェントは、ICEが完了するまでTURNチャネルの作成を延期することをお勧めします。この場合、接続チェックの許可は通常、CreatePermission要求を使用して作成されます。いったん確立されると、エージェントは、ICEが終了するまで許可をアクティブに維持する必要があります。 | |
| 7.1.2。リクエストを送信する | |
| このチェックは、ローカル候補からリモート候補にバインド要求を送信することにより生成されます。[RFC5389]は、バインディング要求がどのように構築および生成されるかを説明しています。接続性チェックは | |
| STUN短期資格情報メカニズムを利用します。RFC 3489との後方互換性のサポートは、接続チェックで使用または想定してはなりません（MUST NOT）。FINGERPRINTメカニズムは、接続性チェックに使用する必要があります。 | |
| ICEは、PRIORITY、USE-CANDIDATE、ICE-CONTROLLED、およびICE-CONTROLLINGを含むいくつかの新しい属性を定義することにより、STUNを拡張します。これらの新しい属性は、セクション19.1で正式に定義されており、その使用法は以下のサブセクションで説明されています。これらのSTUN拡張機能は、ICEに使用される接続チェックにのみ適用できます。 | |
| 7.1.2.1。優先順位と使用候補 | |
| エージェントは、バインディングリクエストにPRIORITY属性を含める必要があります。属性は、セクション4.1.2のアルゴリズムに基づいて、ピアの再帰候補に割り当てられる優先度と等しく設定する必要があります（このチェックの結果として学習される場合は、セクション7.1.3.2.1を参照してください）ピア反射候補者が学習されます）。この優先度の値は、ペアのローカル候補の優先度が計算された方法と同じように計算されますが、タイプの優先順位はピア再帰候補タイプの値に設定されます。 | |
| 制御エージェントは、バインディング要求にUSE-CANDIDATE属性を含めることができます。制御されたエージェントは、バインディングリクエストに含めることはできません。この属性は、制御エージェントがこのコンポーネントのチェックを中止し、このコンポーネントのチェックの結果の候補ペアを使用することを希望していることを通知します。セクション8.1.1は、いつそれを含めるかを決定するためのガイダンスを提供します。 | |
| 7.1.2.2。ICE-CONTROLLEDおよびICE-CONTROLLING | |
| エージェントは、制御された役割にある場合は要求にICE-CONTROLLED属性を含めなければならず、制御する役割にある場合は要求にICE-CONTROLLING属性を含めなければなりません。いずれかの属性の内容は、セクション5.2で決定されたタイブレーカーでなければなりません。これらの属性は、19.1項で完全に定義されています。 | |
| 7.1.2.3。資格情報の形成 | |
| 接続性チェックとして機能するバインディング要求は、STUN短期資格情報メカニズムを利用しなければなりません。資格情報のユーザー名は、ピアによって提供されたユーザー名フラグメントと、要求を送信しているエージェントのユーザー名フラグメントを、コロン（ "："）で区切って連結することにより形成されます。パスワードは、ピアが提供するパスワードと同じです。たとえば、エージェントLが申し出人であり、エージェントRが回答者である場合を考えます。エージェントLには、候補用のLFRAGのユーザー名フラグメントとLPASSのパスワードが含まれていました。エージェントRは、RFRAGのユーザー名フラグメントとRPASSのパスワードを提供しました。LからRへの接続チェックでは、ユーザー名RFRAG：LFRAGとパスワードRPASSを使用します。RからLへの接続チェックでは、ユーザー名LFRAG：RFRAGとパスワードLPASSを使用します。 | |
| 7.1.2.4。DiffServ処理 | |
| エージェントがメディアパケットでDiffserv Codepointマーキング[RFC2475]を使用している場合、接続チェックにそれらの同じマーキングを適用する必要があります。 | |
| 7.1.3。応答の処理 | |
| バインディング応答を受信すると、[RFC5389]で定義されているトランザクションIDを使用してバインディング要求に関連付けられ、バインディング要求が送信された候補ペアに結び付けられます。このセクションでは、STUNのこの使用法に固有のバインディング応答を処理するための追加の手順を定義します。 | |
| 7.1.3.1。失敗事例 | |
| STUNトランザクションが487（Role Conflict）エラー応答を生成する場合、エージェントは、バインディング要求にICE-CONTROLLEDまたはICE-CONTROLLING属性が含まれているかどうかを確認します。要求にICE-CONTROLLED属性が含まれていた場合、エージェントはまだ制御役割に切り替えていない場合、制御役割に切り替えなければなりません。要求にICE-CONTROLLING属性が含まれていた場合、エージェントは、制御された役割にまだ切り替えていない場合は切り替えなければなりません。切り替えが完了すると、エージェントは、チェックが487を生成した候補ペアをトリガーされたチェックキューにキューに入れる必要があります。そのペアの状態は待機中に設定されます。トリガーされたチェックが送信されると、新しい役割を反映するICE-CONTROLLINGまたはICE-CONTROLLED属性が含まれます。ただし、タイブレーカーの値を再選択してはならないことに注意してください。 | |
| ロールの変更では、エージェントがペアの優先度を再計算する必要があります（セクション5.7.2）。これらの優先度は、ロールの制御および制御の機能であるためです。役割の変更は、エージェントが指定されたペアを選択し、ICEの終了時に更新されたオファーを生成する責任があるかどうかにも影響します。 | |
| エージェントは、接続性チェックのためのICMPエラーの受信をサポートする場合があります。STUNトランザクションがICMPエラーを生成した場合、エージェントはペアの状態をFailedに設定します。STUNトランザクションが生成する場合 | |
| （[RFC5389]で定義されている）回復不能またはタイムアウトのSTUNエラー応答。エージェントはペアの状態をFailedに設定します。 | |
| エージェントは、応答のソースIPアドレスとポートが、バインディング要求の送信先の宛先IPアドレスとポートに等しく、応答の宛先IPアドレスとポートが、送信元IPアドレスとポートと一致することを確認する必要があります。バインディングリクエストが送信されました。つまり、要求と応答の送信元と宛先のトランスポートアドレスは対称的です。対称でない場合、エージェントはペアの状態を「失敗」に設定します。 | |
| 7.1.3.2。成功事例 | |
| 次のすべてに該当する場合、チェックは成功と見なされます。 | |
| o STUNトランザクションは成功応答を生成しました。 | |
| o応答のソースIPアドレスとポートは、バインディング要求の送信先IPアドレスとポートと同じです。 | |
| o応答の宛先IPアドレスとポートは、バインディング要求の送信元IPアドレスとポートと一致します。 | |
| 7.1.3.2.1。仲間の再帰候補の発見 | |
| エージェントは、STUN応答からマッピングされたアドレスを確認します。トランスポートアドレスが、エージェントが知っているローカル候補のいずれとも一致しない場合、マッピングアドレスは新しい候補、つまりピア再帰候補を表します。他の候補者と同様に、タイプ、ベース、優先度、および基盤があります。それらは次のように計算されます。 | |
| oそのタイプは、ピア反射型と同等です。 | |
| oそのベースは、STUNチェックが送信された候補ペアのローカル候補に等しく設定されます。 | |
| oその優先度は、バインディング要求のPRIORITY属性の値と等しく設定されます。 | |
| oその基礎は、セクション4.1.1.3で説明されているように選択されます。 | |
| このピア再帰候補は、メディアストリームのローカル候補のリストに追加されます。そのユーザー名フラグメントとパスワードは、そのメディアストリームの他のすべてのローカル候補と同じです。ただし、ピア再帰候補は他のリモート候補とペアになりません。これは必要ありません。セクション7.1.3.2.2の手順に基づいて、一時的に有効なペアが生成されます。エージェントが、ピア反射候補を、生成される有効なペアのペア以外の他のリモート候補とペアリングする場合、エージェントは、ピア反射候補を含む更新されたオファーを生成できます。これにより、他のすべてのリモート候補とペアになります。 | |
| 7.1.3.2.2。有効なペアの構築 | |
| エージェントは、ローカル候補がマッピングされた応答のアドレスに等しく、リモート候補が要求の送信先アドレスに等しい候補ペアを構築します。これは、STUN接続チェックによって検証されているため、有効なペアと呼ばれます。有効なペアは、チェックを生成したペアと等しくても、チェックリスト内の別のペアと等しくても、現在チェックリストにないペアでもかまいません。ペアがチェックを生成したペアまたは現在チェックリストにあるペアと等しい場合、それは有効リストにも追加されます。これは、各メディアストリームのエージェントによって維持されます。このリストはICE処理の開始時には空であり、チェックが実行されると埋められ、有効な候補ペアが作成されます。 | |
| ペアがどのチェックリストにも載らないことは非常に一般的です。チェックリストには、ローカル候補がサーバー反射的ではないペアがあることを思い出してください。これらのペアは、ローカル候補をサーバーの再帰候補のベースに変換し、冗長な場合は剪定します。STUNチェックへの応答が到着すると、2つの間にNATがある場合、マッピングアドレスは再帰的になります。その場合、有効なペアには、チェックリスト内のどのペアとも一致しないローカル候補があります。 | |
| ペアがチェックリストにない場合、エージェントはセクション5.7のアルゴリズムを使用して、各候補の優先度に基づいてペアの優先度を計算します。ローカル候補者の優先順位は、そのタイプによって異なります。ピア反射型ではない場合、SDPのその候補に対して通知された優先順位と等しくなります。ピア再帰的である場合、それは、完了したばかりのバインディング要求にエージェントが配置したPRIORITY属性と同じです。リモート候補の優先度は、ピアのSDPから取得されます。候補がそこに表示されない場合、チェックは新しいリモート候補に対するトリガーチェックである必要があります。その場合、優先度は、完了したチェックをトリガーしたバインディングリクエストのPRIORITY属性の値として使用されます。ペアは有効リストに追加されます。 | |
| 7.1.3.2.3。ペア状態の更新 | |
| エージェントは、チェックを*生成*したペアの状態をSucceededに設定します。チェックを*生成*したペアは、応答の結果としてセクション7.1.3.2.2で構築された有効なペアと異なる場合があることに注意してください。このチェックが成功すると、他のチェックの状態も変更される場合があります。エージェントは、次の2つの手順を実行する必要があります。 | |
| 1.エージェントは、同じメディアストリームおよび同じ基盤のその他すべてのフローズンペアの状態を待機中に変更します。通常、ただし常にではありませんが、これらの他のペアには異なるコンポーネントIDがあります。 | |
| 2.このメディアストリームのすべてのコンポーネントの有効なリストにペアがある場合（これは使用されるコンポーネントの実際の数であり、SDPで通知されるコンポーネントの数が提供者と回答者で異なる場合）、成功このチェックのうち、他のメディアストリームのチェックをフリーズ解除する場合があります。このステップは、検討中の有効なリストにすべてのコンポーネントのペアが初めてあるときだけでなく、その後のチェックが成功してその有効なリストにさらに別のペアが追加されるたびに実行されることに注意してください。エージェントは、各メディアストリームのチェックリストを順番に調べます。 | |
| *チェックリストがアクティブな場合、エージェントは、そのチェックリスト内のすべてのフローズンペアの状態を、基礎が有効なリスト内のペアと一致するものを、待機中に変更します。 | |
| *チェックリストが凍結されており、検討中の有効なリストのペアと一致する基盤を持つチェックリストに少なくとも1つのペアがある場合、基盤が有効なリストのペアと一致するチェックリスト内のすべてのペアの状態考慮は待機中に設定されます。これにより、チェックリストがアクティブになり、セクション5.8で説明されているように、通常のチェックが開始されます。 | |
| *チェックリストがフリーズされ、検討中の有効なリストのペアに一致する基盤を持つチェックリストにペアがない場合、エージェントは | |
| +同じ基盤を持つすべてのペアをグループ化する | |
| +グループごとに、最小のコンポーネントIDを持つペアの状態を待機中に設定します。そのようなペアが複数ある場合、最も優先度の高いペアが使用されます。 | |
| 7.1.3.2.4。ノミネートされたフラグの更新 | |
| エージェントが制御エージェントであり、バインド要求にUSE-CANDIDATE属性が含まれていた場合、そのチェックから生成された有効なペアのノミネートフラグはtrueに設定されます。このフラグは、指定されたフラグが設定されているメディアの中で最も優先度の高いものである場合、この有効なペアをメディアに使用することを示します。これにより、このメディアストリームまたはすべてのメディアストリームのICE処理が終了する場合があります。セクション8を参照してください。 | |
| エージェントが制御されたエージェントである場合、応答は、それ自体がUSE-CANDIDATE属性を持っていた要求への応答として送信されたトリガーチェックの結果である場合があります。この場合はセクション7.2.1.5で説明されており、元のリクエストから学習したペアに指定フラグが設定される可能性があります。 | |
| 7.1.3.3。チェックリストとタイマー状態の更新 | |
| チェックが成功したか失敗したかに関係なく、トランザクションの完了にはチェックリストとタイマーの状態の更新が必要になる場合があります。 | |
| チェックリスト内のすべてのペアが失敗または成功のいずれかの状態になった場合： | |
| oメディアストリームの各コンポーネントの有効なリストにペアがない場合、チェックリストの状態は[失敗]に設定されます。 | |
| o凍結チェックリストごとに、エージェント | |
| *同じ基盤を持つすべてのペアをグループ化する | |
| *各グループに対して、最も低いコンポーネントIDを持つペアの状態を待機中に設定します。そのようなペアが複数ある場合、最も優先度の高いペアが使用されます。 | |
| チェックリスト内のペアのいずれも待機中または凍結状態にない場合、チェックリストはアクティブであると見なされなくなり、セクション5.8で説明されている通常のチェックのタイマーの計算でNの値にカウントされません。 | |
| 7.2。STUNサーバーの手順 | |
| エージェントは、最新のオファーまたはアンサーに含まれる各候補のベースでバインディングリクエストを受信する準備をする必要があります。この要件は、ピアがライト実装であっても保持されます。 | |
| エージェントは、短期の資格情報を使用して要求を認証し、メッセージの整合性チェックを実行する必要があります。エージェントは、コロンで区切られた2つの値で構成される場合、ユーザー名が有効であると見なしなければなりません。最初の値は、進行中のセッションのオファーまたはアンサーでエージェントによって生成されたユーザー名フラグメントと等しくなります。オファー側がピアから回答を受信する前にバインディング要求を受信する可能性があります（実際には非常に可能性が高い）。これが発生した場合、エージェントはすぐに応答を生成する必要があります（セクション7.2.1.2で説明されているマッピングアドレスの計算を含む）。この時点で、エージェントは応答を生成するのに十分な情報を持っています。ピアからのパスワードは不要です。回答を受け取ったら、必要な残りの手順、つまり7.2.1.3、7.2.1.4、および7.2.1に進む必要があります。完全実装の場合は5。回答の前に複数のSTUN要求を受信した場合、これにより、トリガーされたチェックキューにいくつかのペアがキューイングされる可能性があります。 | |
| エージェントは、ALTERNATE-SERVERメカニズムを利用してはならず、RFC 3489への後方互換性メカニズムをサポートしてはなりません。FINGERPRINTメカニズムを利用しなければなりません。 | |
| エージェントがメディアパケットでDiffserv Codepointマーキング[RFC2475]を使用している場合、バインディングリクエストへの応答にそれらの同じマーキングを適用する必要があります。同じことが、エンドポイントがメディアパケットに適用する可能性のあるレイヤー2マーキングにも適用されます。 | |
| 7.2.1。完全な実装のための追加手順 | |
| このサブセクションでは、完全な実装に適用可能な追加のサーバー手順を定義します。 | |
| 7.2.1.1。ロールの競合の検出と修復 | |
| 通常、セクション5.2のロールの選択に関する規則により、各エージェントは異なるロールを選択します。1つの制御と1つの制御です。ただし、通常はサードパーティのコール制御を利用する異常なコールフローでは、両方のエージェントが同じ役割を選択する可能性があります。このセクションでは、このケースを確認して修復する手順について説明します。 | |
| エージェントは、ICE-CONTROLLINGまたはICE-CONTROLLED属性のいずれかのバインディング要求を検査する必要があります。次の手順に従う必要があります。 | |
| o ICE-CONTROLLINGもICE-CONTROLLEDも要求に存在しない場合、ピアエージェントはこの仕様の以前のバージョンを実装している可能性があります。競合がある可能性がありますが、検出できません。oエージェントが制御ロールにあり、リクエストにICE-CONTROLLING属性が存在する場合： | |
| *エージェントのタイブレーカーがICE-CONTROLLING属性のコンテンツ以上の場合、エージェントはバインディングエラー応答を生成し、487（ロールの競合）の値を持つERROR-CODE属性を含めますが、その役割は保持します。 | |
| *エージェントのタイブレーカーがICE-CONTROLLING属性の内容よりも小さい場合、エージェントは制御された役割に切り替わります。 | |
| oエージェントが制御された役割にあり、リクエストにICE-CONTROLLED属性が存在する場合： | |
| *エージェントのタイブレーカーがICE-CONTROLLED属性の内容以上の場合、エージェントは制御ロールに切り替わります。 | |
| *エージェントのタイブレーカーがICE-CONTROLLED属性の内容よりも小さい場合、エージェントはバインディングエラー応答を生成し、値487（ロール競合）のERROR-CODE属性を含めますが、その役割は保持します。 | |
| oエージェントが制御ロールにあり、リクエストにICE-CONTROLLING属性が存在する場合、またはエージェントがコントロールロールにあり、リクエストにICE-CONTROLLED属性が存在する場合、競合はありません。 | |
| 役割の変更には、ペアの優先順位（セクション5.7.2）を再計算するエージェントが必要です。これらの優先順位は、制御および制御される役割の機能であるためです。役割の変更は、ICEの終了時にエージェントが指名されたペアを選択し、更新されたオファーを生成する責任があるかどうかにも影響します。 | |
| エージェントがロールを変更した場合でも、サーバーがバインディング要求に対する正常な応答を生成した場合、セクション7.2.1の残りのセクションが続きます。 | |
| 7.2.1.2。マッピングアドレスの計算 | |
| リレーされた候補で受信される要求の場合、STUN処理（つまり、XOR-MAPPED-ADDRESS属性の生成）に使用されるソーストランスポートアドレスは、TURNサーバーから見たトランスポートアドレスです。バインディング要求がデータ表示を通じて配信された場合、そのソーストランスポートアドレスは、データ表示メッセージのXOR-PEER-ADDRESS属性に存在します。もし | |
| バインディング要求はChannelDataメッセージを介して配信され、ソーストランスポートアドレスはチャネルにバインドされたものです。 | |
| 7.2.1.3。仲間の再帰候補の学習 | |
| 要求の送信元トランスポートアドレスが既存のリモート候補のいずれとも一致しない場合、新しいピア反射リモート候補を表します。この候補は次のように構成されています。 | |
| o候補の優先度は、リクエストのPRIORITY属性に設定されます。 | |
| o候補のタイプは、ピア再帰に設定されます。 | |
| o候補の基礎は、他のすべてのリモート候補の基礎とは異なる任意の値に設定されます。後続のオファー/アンサー交換にSDPでこのピア再帰候補が含まれている場合、候補の実際の基盤を示します。 | |
| oこの候補のコンポーネントIDは、リクエストが送信されたローカル候補のコンポーネントIDに設定されます。 | |
| この候補は、リモート候補のリストに追加されます。ただし、エージェントはこの候補をローカル候補とペアリングしません。 | |
| 7.2.1.4。トリガーチェック | |
| 次に、エージェントは、ローカル候補がSTUN要求を受信したトランスポートアドレスに等しいペアと、要求の送信元であるソーストランスポートアドレスに等しいリモート候補を作成します（これは、学んだばかり）。ローカル候補は、ホスト候補（要求がリレー経由で受信されなかった場合）またはリレーされた候補（リレー経由で受信された場合）のいずれかになります。ローカル候補者は、サーバーの再帰候補者になることはできません。両方の候補がエージェントに認識されているため、エージェントは優先度を取得し、候補ペアの優先度を計算できます。このペアは、チェックリストで検索されます。いくつかの結果のいずれかがあります。 | |
| oペアがすでにチェックリストにある場合： | |
| *そのペアの状態がWaitingまたはFrozenの場合、そのペアのチェックは、まだ存在しない場合、トリガーされたチェックキューにキューイングされます。 | |
| *そのペアの状態が進行中の場合、エージェントは進行中のトランザクションをキャンセルします。キャンセルとは、エージェントがリクエストを再送信せず、応答の欠如を失敗として扱わず、トランザクションタイムアウトの期間だけ応答を待つことを意味します。さらに、エージェントは、トリガーされたチェックキューにペアをエンキューして、そのペア（新しいSTUNバインディング要求トランザクションを表す）の新しい接続チェックを作成する必要があります。ペアの状態は、待機中に変更されます。 | |
| *ペアの状態が[失敗]の場合、待機中に変更され、エージェントはトリガーされたチェックキューにペアをエンキューして、そのペアの新しい接続チェック（新しいSTUNバインディング要求トランザクションを表す）を作成する必要があります。 | |
| *そのペアの状態がSucceededの場合、それ以上何も行われません。 | |
| これらの手順は、両方のエージェントがNATの背後にある場合にICEの迅速な完了を促進するために行われます。 | |
| oペアがまだチェックリストにない場合： | |
| *ペアは、優先度に基づいてチェックリストに挿入されます。 | |
| *その状態は待機中に設定されます。 | |
| *ペアはトリガーされたチェックキューに入れられます。 | |
| トリガーされたチェックが送信される場合、セクション7.1.2で説明されているように構築および処理されます。これらの手順では、エージェントがピアのトランスポートアドレス、ユーザー名フラグメント、およびパスワードを知っている必要があります。リモート候補のユーザー名フラグメントは、受信したバインディングリクエストのUSERNAMEのコロンの後の部分と同じです。そのユーザー名フラグメントを使用して、エージェントはピアから受信したSDPメッセージを確認し（分岐の場合は複数ある可能性があります）、このユーザー名フラグメントを見つけることができます。次に、対応するパスワードが選択されます。 | |
| 7.2.1.5。ノミネートされたフラグの更新 | |
| エージェントが受け取ったバインディング要求にUSE-CANDIDATE属性が設定されていて、エージェントが制御された役割にある場合、エージェントはセクション7.2.1.4で計算されたペアの状態を調べます。 | |
| oこのペアの状態がSucceededの場合、このペアによって生成されたチェックが成功した応答を生成したことを意味します。これにより、エージェントは、成功応答を受信したときに有効なペアを構築していました（セクション7.1.3.2.2を参照）。エージェントは、有効なペアの指定されたフラグをtrueに設定するようになりました。これにより、このメディアストリームのICE処理が終了する場合があります。セクション8を参照してください。 | |
| oこのペアの状態がIn-Progressの場合、チェックで成功した場合、結果の有効なペアには、応答が到着したときに指定されたフラグが設定されます。これにより、このメディアストリームの到着時にICE処理が終了する場合があります。セクション8を参照してください。 | |
| 7.2.2。Lite実装の追加手順 | |
| 受信したチェックにUSE-CANDIDATE属性が含まれていた場合、エージェントは候補ペアを作成します。候補ペアは、ローカル候補がリクエストを受信したトランスポートアドレスと等しく、リモート候補がリクエストのソーストランスポートアドレスと等しいそれは受け取られました。この候補ペアには、任意の優先度が割り当てられ、有効リストと呼ばれる有効な候補のリストに配置されます。エージェントは、そのペアの指定フラグをtrueに設定します。有効なリストに各コンポーネントの候補ペアが含まれている場合、メディアストリームのICE処理は完了したと見なされます。 | |
| 8. ICE処理の終了 | |
| このセクションでは、エージェントがICEを完了する方法について説明します。 | |
| 8.1。完全な実装の手順 | |
| ICEの締結には、制御エージェントによるペアの指定と、状態機械の更新が含まれます。 | |
| 8.1.1。指名ペア | |
| 制御エージェントは、通常の指名または積極的な指名の2つの手法のいずれかを使用して、ICEによって選択されるペアを指名します。ピアにライト実装がある場合、エージェントは通常の指名アルゴリズムを使用する必要があります。そのピアが、エージェントが理解しないICEオプション（ピアからのice-options属性に存在する）を使用している場合、エージェントは通常の指名アルゴリズムを使用しなければなりません（MUST）。ピアが完全な実装であり、ICEオプションを使用していない場合、またはエージェントが理解するICEオプションを使用している場合、エージェントは積極的または通常のノミネートアルゴリズムを使用できます。ただし、通常のアルゴリズムは安定性が高いため、推奨されます。 | |
| 8.1.1.1。定期的な推薦 | |
| 通常の指名では、エージェントはいくつかのチェックを完了させ、それぞれのチェックでUSE-CANDIDATE属性を省略します。メディアストリームのコンポーネントの1つ以上のチェックが正常に完了すると、有効なペアが生成され、有効なリストに追加されます。エージェントは、いくつかの停止基準が満たされるまでチェックを継続させ、その後、評価基準に基づいて有効なペアの中から選択します。チェックを停止し、有効なペアを評価するための基準は、完全にローカルな最適化の問題です。 | |
| 制御エージェントが有効なペアを選択すると、この有効なペアを生成したチェックを繰り返します（トリガーチェックキューにチェックを生成したペアをエンキューすることにより）。今回はUSE-CANDIDATE属性を使用します。このチェックは成功するはずです（以前のように）、その指定されたフラグとそのペアのみが設定されます。その結果、各コンポーネントの有効なリストには指定されたペアが1つだけ存在し、チェックリストの状態が完了に移行すると、ICEによってそのコンポーネントのメディアを送受信するために正確なペアが選択されます。 | |
| エージェントがチェックの停止および選択基準を制御できるため、定期的な指名が最も柔軟性を提供します。唯一の要件は、エージェントが最終的に1つだけの候補ペアを選択し、USE-CANDIDATE属性が存在するそのペアのチェックを生成する必要があることです。定期的な指名により、実装のバリエーションに対するICEの回復力も向上します（セクション14を参照）。定期的な指名もより安定しているため、一時的な選択なしで両方のエージェントがメディアの単一のペアに収束できます。これはアグレッシブアルゴリズムで発生する可能性があります。定期的な指名の欠点は、追加のチェックを行う必要があるため、レイテンシーの増加が保証されることです。 | |
| 8.1.1.2。積極的な指名 | |
| 積極的な指名では、制御エージェントは送信するすべてのチェックにUSE-CANDIDATE属性を含めます。コンポーネントの最初のチェックが成功すると、有効なリストに追加され、指定されたフラグが設定されます。すべてのコンポーネントが有効なリストに指定されたペアを持っている場合、メディアは最も優先度の高い指定されたペアを使用してフローを開始できます。ただし、エージェントのすべてのチェックにUSE-CANDIDATE属性が含まれているため、別のチェックがまだ完了しており、別の有効なペアに指定されたフラグが設定されている可能性があります。ICEは、メディアに使用されるものとして、常に有効なリストから最も優先度の高い候補者ペアを選択します。その結果、ICEチェックが完了すると、選択されたペアが実際に短時間変化し、安定するまで一時的な選択が行われる可能性があります。 | |
| 8.1.2。状態の更新 | |
| 制御エージェントと制御エージェントの両方について、ICE処理の状態は、有効なリスト内の指定された候補ペアの存在とチェックリストの状態に依存します。いつでも、次のケースの複数が適用されることに注意してください。 | |
| oメディアストリームの有効なリストに指定されたペアがなく、チェックリストの状態が実行中の場合、ICE処理が続行されます。 | |
| oメディアストリームの有効なリストに指定されたペアが少なくとも1つあり、チェックリストの状態が実行中の場合： | |
| *エージェントは、チェックリスト内のすべての待機ペアと凍結ペアを削除し、そのメディアストリームの指定ペアと同じコンポーネントのチェックキューをトリガーする必要があります。 | |
| *チェックリストの進行中のペアが指定されたペアと同じコンポーネント用である場合、ペアの優先度がそのコンポーネントの最低優先度の指定されたペアよりも低い場合、エージェントはチェックの再送信を停止する必要があります。 | |
| o少なくとも1つのメディアストリームのすべてのコンポーネントの有効なリストに少なくとも1つの指定ペアがあり、チェックリストの状態が実行中の場合： | |
| *エージェントは、そのメディアストリームのチェックリストの処理状態をCompletedに変更する必要があります。 | |
| *エージェントは、そのメディアストリームに対してまだ受信する可能性のあるすべてのチェックに応答し続けなければならず、セクション7.2の処理で必要な場合はトリガーチェックを実行する必要があります。 | |
| *エージェントは、そのチェックリストの進行中のチェックを再送信し続ける必要があります。 | |
| *エージェントは、セクション11.1で説明されているように、このメディアストリームのメディアの送信を開始できます。 | |
| o各チェックリストの状態が完了したら： | |
| *エージェントは、ICE処理全体の状態を完了に設定します。 | |
| *エージェントが制御している場合、各メディアストリームの各コンポーネントの最高優先度の候補候補ペアを調べます。これらの候補ペアのいずれかが最新のオファー/アンサー交換のデフォルトの候補ペアと異なる場合、制御エージェントはセクション9で説明されているように更新されたオファーを生成する必要があります。メディアの変更のために選択されたペアに応じて、いくつかの更新されたオファー エージェントは、選択されたペアを安定させるために、短い間隔（1秒が推奨される）でオファーの送信を遅らせる場合があります。 | |
| oチェックリストの状態が[失敗]の場合、ICEはこのメディアストリームを完了できませんでした。正しい動作は、他のメディアストリームのチェックリストの状態によって異なります。 | |
| *すべてのチェックリストが失敗した場合、ICE処理全体は失敗状態にあると見なされ、エージェントはセッションを失敗と見なすべきであり（SHOULD NOT ICE）、制御エージェントはセッション全体を終了すべきです（SHOULD NOT）。 | |
| *他のメディアストリームのチェックリストの少なくとも1つが完了している場合、制御エージェントは、更新されたオファーのセッションから失敗したメディアストリームを削除する必要があります。 | |
| *他のメディアストリームのチェックリストのいずれも完了していないが、少なくとも1つが実行されている場合、エージェントはICEを続行する必要があります。 | |
| 8.2。Lite実装の手順 | |
| ライト実装のためのICEの結論は比較的簡単です。考慮すべき2つのケースがあります。 | |
| 実装はライトであり、そのピアはいっぱいです。 | |
| 実装はライトであり、そのピアはライトです。 | |
| ICEの結論の効果は、セクション8.3で説明されているように、エージェントがICEによって使用されなかった割り当てられたホスト候補を解放できることです。 | |
| 8.2.1。ピアがいっぱいです | |
| この場合、エージェントはピアから接続チェックを受け取ります。エージェントがメディアストリームの各コンポーネントのUSE-CANDIDATE属性を含む接続性チェックを受信すると、そのメディアストリームのICE処理の状態は実行中から完了に移行します。すべてのメディアストリームのICE処理の状態が完了すると、ICE処理全体の状態が完了します。 | |
| ライトの実装自体は、メディアストリームのICE処理が失敗したと判断することはありません。むしろ、完全なピアがその決定を行い、その後のオファーで失敗したメディアストリームを削除または再起動します。 | |
| 8.2.2。Peer Is Lite | |
| オファー/アンサー交換が完了すると、両方のエージェントが候補者とそのピアの候補者を調べます。各エージェントは、メディアストリームごとに、そのメディアストリームのピアの候補と独自の候補をペアにします。2つの候補は、同じコンポーネント用であり、同じトランスポートプロトコル（この仕様ではUDP）を使用し、同じIPアドレスファミリ（IPv4またはIPv6）からのものである場合にペアになります。 | |
| oコンポーネントごとに1つのペアがある場合、そのペアは有効リストに追加されます。メディアストリームのすべてのコンポーネントに1つのペアがある場合、そのメディアストリームのICE処理の状態は完了に設定されます。すべてのメディアストリームが完了した場合、ICE処理の状態は全体的に完了に設定されます。これは、IPv4のみの実装の場合に常に当てはまります。 | |
| oコンポーネントごとに複数のペアがある場合： | |
| *エージェントは、ローカルポリシーに基づいてペアを選択する必要があります。このケースはIPv6でのみ発生するため、エージェントがRFC 3484 [RFC3484]の手順に従って単一のペアを選択することをお勧めします。 | |
| *エージェントは、各コンポーネントの選択されたペアを有効なリストに追加します。セクション11.1で説明したように、これによりメディアのフローが開始されます。ただし、両方のエージェントが異なるペアを選択している可能性があります（実際はそうである可能性があります）。 | |
| *これを調整するために、制御エージェントは、セクション9.1.3で説明されているように、リモート候補属性を含む更新されたオファーを送信する必要があります。 | |
| *エージェントは、オファーの送信時にICE処理の状態を更新してはなりません。この後続のオファーが完了すると、制御エージェントは、すべてのメディアストリームのICE処理の状態をCompletedに変更し、全体的なICE処理の状態をCompletedに変更する必要があります。制御対象エージェントの状態は、セクション9.2.3のロジックに基づいて設定されます。 | |
| 8.3。候補者の解放 | |
| 8.3.1。完全な実装手順 | |
| セクション8の手順では、そのストリームの処理が完了した後でも、エージェントがSTUN要求をリッスンし続け、メディアストリームのトリガーチェックを生成し続けることが必要です。このセクションのルールでは、エージェントがICEによって選択されなかった候補のチェックの送信または受信を停止し、候補を解放しても安全である場合について説明します。 | |
| SIPでICEが使用され、オファーが複数の受信者に分岐されると、ICEは各回答者と並行して独立して進行し、すべて同じローカル候補を使用します。ICE処理がこれらの候補を使用するメディアストリームのすべてのピアの完了状態に達すると、エージェントはさらに3秒間待機する必要があります（SHOULD）。その時点で候補者を解放することができます。サーバーの再帰候補の解放は決して明示的ではありません。それはキープアライブの欠如によって起こります。3秒間の遅延は、積極的な指名が使用される場合を処理し、選択されたペアは、ICEの完了後すぐに変更できます。 | |
| 8.3.2。Liteの実装手順 | |
| ライトの実装は、ICE処理がそれらの候補を使用するすべてのメディアストリームのすべてのピアの完了状態に達するとすぐに、ICEによって選択されない候補を解放することができます。 | |
| 9.その後のオファー/アンサー交換 | |
| どちらのエージェントも、RFC 3264 [RFC3264]で許可されているいつでも後続のオファーを生成できます。セクション8のルールにより、ICEがデフォルトのペアから異なる候補ペアを選択した場合、ICE処理の終了時に、制御エージェントが更新されたオファーを送信します。このセクションでは、後続のオファーとアンサーの構築に関するルールを定義します。 | |
| 後続のオファーが拒否された場合、ICE処理は後続のオファーが行われなかったかのように続行します。 | |
| 9.1。オファーの生成 | |
| 9.1.1。すべての実装の手順 | |
| 9.1.1.1。ICE再起動 | |
| エージェントは、既存のメディアストリームのICE処理を再開できます。名前が示すように、ICEを再起動すると、ICE処理の以前のすべての状態がフラッシュされ、チェックが新たに開始されます。ICEの再起動とまったく新しいメディアセッションの唯一の違いは、再起動中に、以前に検証されたペアにメディアを送信し続けることができることです。 | |
| 次の場合、エージェントはメディアストリームのICEを再起動する必要があります。 | |
| oオファーは、メディアストリームのターゲットを変更する目的で生成されています。言い換えると、エージェントが、ICEが使用されていなかった場合に、メディアコンポーネントの宛先に新しい値をもたらす更新されたオファーを生成したい場合です。 | |
| oエージェントが実装レベルを変更しています。これは通常、シグナリングを実行するエンティティがメディアを受信するエンティティではなく、メディアの中間セッションのターゲットを別のICE実装を持つ別のエンティティに変更したサードパーティのコール制御ユースケースでのみ発生します。 | |
| これらのルールは、c行のIPアドレスを0.0.0.0に設定すると、ICEが再起動することを意味します。その結果、ICE実装はこのメカニズムを通話保留に利用してはならず、代わりに[RFC3264]で説明されているようにa = inactiveおよびa = sendonlyを使用しなければなりません。 | |
| ICEを再起動するには、エージェントはオファー内のメディアストリームのice-pwdとice-ufragの両方を変更する必要があります。1つのオファーでセッションレベルの属性を使用することは許可されますが、後続のオファーでメディアレベルの属性と同じice-pwdまたはice-ufragを提供することに注意してください。これはパスワードの変更ではなく、単に表現の変更であり、ICEの再起動は発生しません。 | |
| エージェントは、このメディアストリームの最初のオファーと同様に、このメディアストリームのSDPの残りのフィールドを設定します（セクション4.3を参照）。その結果、候補のセットには、そのストリームの以前の候補の一部、なし、またはすべてを含めることができ（MAY）、セクション4.1.1で説明したように収集したまったく新しい候補のセットを含めることができます。 | |
| 9.1.1.2。メディアストリームの削除 | |
| エージェントがポートをゼロに設定してメディアストリームを削除する場合、そのメディアストリームの候補属性を含めることはできません。また、そのメディアストリームに対してセクション15で定義されている他のICE関連属性を含めることはできません。 | |
| 9.1.1.3。メディアストリームの追加 | |
| エージェントが新しいメディアストリームを追加する場合、このメディアストリームのSDPのフィールドを、これがそのメディアストリームの初期オファーであるかのように設定します（セクション4.3を参照）。これにより、このメディアストリームのICE処理が開始されます。 | |
| 9.1.2。完全な実装の手順 | |
| このセクションでは、既存のメディアストリームを対象に、完全な実装の追加手順について説明します。 | |
| ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用したものと同じままにする必要があります。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームのICEを再起動する必要があります。 | |
| 追加の動作は、そのメディアストリームの状態ICE処理に依存します。 | |
| 9.1.2.1。ICE実行中の既存のメディアストリーム | |
| エージェントが以前に確立されたメディアストリームを含む更新されたオファーを生成し、ICEチェックが実行状態にある場合、エージェントはここで定義された手順に従います。 | |
| エージェントは、そのメディアストリームについて以前に通知したすべてのローカル候補の候補属性を含める必要があります。SDPで通知されたその候補のプロパティ（優先度、基盤、タイプ、および関連するトランスポートアドレス）は、同じままにする必要があります。基本的にその候補を識別するIPアドレス、ポート、およびトランスポートプロトコルは同じままでなければなりません（変更する場合、新しい候補になります）。コンポーネントIDは同じままでなければなりません。エージェントには、以前は提供していなかったが、最後のオファー/アンサー交換以降に収集した、ピア反射候補者を含む追加の候補者を含めることができます。 | |
| エージェントは、メディアのデフォルトの宛先を変更する場合があります。初期オファーと同様に、このデフォルトの宛先に一致するオファーには候補属性のセットがなければなりません。 | |
| 9.1.2.2。ICEが完了した既存のメディアストリーム | |
| エージェントが以前に確立されたメディアストリームを含む更新されたオファーを生成し、ICEチェックが完了状態にある場合、エージェントはここで定義された手順に従います。 | |
| メディアのデフォルトの宛先（つまり、そのメディアストリームに使用されるmおよびc行のIPアドレスとポートの値）は、各コンポーネントの有効なリストで最も優先度の高い指定ペアからのローカル候補でなければなりません。これにより、メディアのデフォルトの宛先が、ICEがメディア用に選択した宛先と等しくなるように「修正」されます。 | |
| エージェントは、メディアストリームの各コンポーネントのデフォルトの宛先に一致する候補の候補属性を含めなければならず、他の候補を含めてはなりません。 | |
| さらに、エージェントが制御している場合、チェックリストが完了状態にある各メディアストリームのa = remote-candidates属性を含める必要があります。この属性には、そのメディアストリームの各コンポーネントの有効なリストにある最も優先度の高い候補ペアからのリモート候補が含まれています。制御エージェントがそのペアを選択する競合状態を回避する必要がありますが、更新されたオファーは、これらのペアが有効であることを知らず、選択はもちろんのこと、制御エージェントへの接続チェックを破ります。この競合状態の詳細については、付録B.6を参照してください。 | |
| 9.1.3。Lite実装の手順 | |
| 9.1.3.1。ICE実行中の既存のメディアストリーム | |
| このセクションでは、ICEが実行されている既存のストリームの簡易実装の手順について説明します。 | |
| ライトの実装では、後続のオファーのa = candidate属性に、各メディアストリームの各コンポーネントのすべての候補を含める必要があります。これらの候補は、セクション4.2で説明されているように、初期オファーの手順と同じように形成されます。 | |
| ライトの実装では、後続のオファーで追加のホスト候補を追加してはなりません。エージェントが追加の候補を提供する必要がある場合、ICEを再起動する必要があります。 | |
| ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用したものと同じままにする必要があります。エージェントがこれらのいずれかを変更する必要がある場合、そのメディアストリームのICEを再起動する必要があります。 | |
| 9.1.3.2。ICEが完了した既存のメディアストリーム | |
| メディアストリームのICEが完了した場合、そのメディアストリームのデフォルトの宛先は、有効なリスト内のそのコンポーネントの候補ペアのリモート候補に設定する必要があります。ライト実装の場合、メディアストリームの各コンポーネントの有効なリストには常に1つの候補ペアのみが存在します。さらに、エージェントは各デフォルト宛先の候補属性を含める必要があります。 | |
| さらに、エージェントが制御している場合（両方のエージェントがライトの場合にのみ発生します）、エージェントは各メディアストリームにa = remote-candidates属性を含めなければなりません（MUST）。この属性には、有効なリスト内の候補ペア（各メディアストリームのコンポーネントごとに1つのペア）からのリモート候補が含まれます。 | |
| 9.2。オファーの受信と回答の生成 | |
| 9.2.1。すべての実装の手順 | |
| 既存のセッション内で後続のオファーを受信する場合、エージェントは、以前のオファー/アンサー交換からの検証結果に関係なく、セクション5.1の検証手順を再適用する必要があります。実際、以前のオファー/アンサー交換によりICEが使用されなかった可能性がありますが、その後の交換の結果として使用されます。 | |
| 9.2.1.1。ICE再起動の検出 | |
| オファーに、ピアからの以前のSDPと比較してa = ice-ufragまたはa = ice-pwd属性の変更が含まれていた場合、ICEがこのメディアストリームに対して再起動していることを示します。すべてのメディアストリームが再起動している場合、ICEは全体的に再起動しています。 | |
| ICEがメディアストリームに対して再起動している場合： | |
| oエージェントは、回答のa = ice-ufragおよびa = ice-pwd属性を変更しなければなりません。 | |
| oエージェントは、回答の実装レベルを変更できます。 | |
| エージェントは、このメディアストリームに対する最初の回答と同様に、このメディアストリームのSDPの残りのフィールドを設定します（セクション4.3を参照）。その結果、候補のセットには、そのストリームの以前の候補の一部、なし、またはすべてを含めることができ（MAY）、セクション4.1.1で説明したように収集したまったく新しい候補のセットを含めることができます。 | |
| 9.2.1.2。新しいメディアストリーム | |
| オファーに新しいメディアストリームが含まれている場合、エージェントは、そのメディアストリームを含む最初のオファーを受信したかのように回答のフィールドを設定します（セクション4.3を参照）。これにより、このメディアストリームのICE処理が開始されます。 | |
| 9.2.1.3。削除されたメディアストリーム | |
| オファーにポートがゼロのメディアストリームが含まれる場合、エージェントはそのメディアストリームの候補属性を回答に含めてはならず、セクション15でそのメディアストリームに対して定義されている他のICE関連属性を含めるべきではありません。 | |
| 9.2.2。完全な実装の手順 | |
| エージェントがオファーからICEの再起動を検出しない限り、ユーザー名フラグメント、パスワード、および実装レベルは、以前に使用したものと同じままでなければなりません。エージェントがこれらのいずれかを変更する必要がある場合、オファーを生成することにより、そのメディアストリームのICEを再起動する必要があります。ICEは回答で再起動できません。 | |
| 追加の動作は、そのメディアストリームのICE処理の状態に依存します。 | |
| 9.2.2.1。ICEが実行され、リモート候補がない既存のメディアストリーム | |
| ICEがメディアストリームに対して実行されており、そのメディアストリームのオファーにremote-candidates属性がない場合、回答の構築のルールは、セクション9.1.2.1で説明されているオファーのルールと同じです。 | |
| 9.2.2.2。ICEを使用した既存のメディアストリームが完了し、リモート候補はありません | |
| メディアストリームのICEが完了し、そのメディアストリームのオファーにremote-candidates属性がない場合、回答の構築のルールは、回答者が必須である点を除き、セクション9.1.2.2で説明したオファーのルールと同じです。回答にa = remote-candidates属性を含めないでください。 | |
| 9.2.2.3。既存のメディアストリームとリモート候補 | |
| 制御されたエージェントは、ピアがそのメディアストリームのICE処理を完了したときに、メディアストリームのa = remote-candidates属性を持つオファーを受け取ります。この属性は、オファーの受信と、ICEによって選択される候補者を回答者に通知するBinding応答の受信との間の競合状態を処理するためのオファーに存在します。この競合状態の説明については、付録B.6を参照してください。したがって、この属性を使用したオファーの処理は、レースの勝者によって異なります。 | |
| エージェントは、次の方法でメディアストリームの各コンポーネントの候補ペアを形成します。 | |
| oリモート候補をそのコンポーネントの提供者のデフォルトの宛先と等しく設定する（たとえば、RTPのmおよびc行の内容、およびRTCPのa = rtcp属性） | |
| oオファーのa = remote-candidates属性で、同じコンポーネントのトランスポートアドレスに等しいローカル候補を設定します。 | |
| エージェントは、これらの候補ペアのそれぞれが有効なリストに存在するかどうかを確認します。特定のペアが有効なリストにない場合、チェックはレースを「失いました」。そのようなペアを「負けペア」と呼びます。 | |
| エージェントは、チェックリスト内のすべてのペアを見つけます。そのペアのリモート候補は、失われたペアのリモート候補と等しくなります。 | |
| o進行中のペアがなく、少なくとも1つのペアが失敗した場合、ネットワークパーティションや重大なパケット損失などのネットワーク障害が発生している可能性があります。エージェントは、リモート候補属性が存在していないかのように、このメディアストリームの回答を生成する必要があります。次に、このストリームのICEを再起動します。 | |
| o少なくとも1つのペアが進行中の場合、エージェントはそれらのチェックが完了するまで待機する必要があり（SHOULD）、それぞれのチェックが完了すると、失われるペアがなくなるまでこのセクションの処理をやり直します。 | |
| 負けたペアがなくなると、エージェントは回答を生成できます。メディアのデフォルトの宛先を、オファーのremote-candidates属性の候補に設定する必要があります（各候補は、有効なリストの候補ペアのローカル候補になります）。オファーのremote-candidates属性の各候補の回答に候補属性を含める必要があります。 | |
| 9.2.3。Lite実装の手順 | |
| 受信したオファーにメディアストリームのremote-candidates属性が含まれている場合、エージェントは次の方法でメディアストリームの各コンポーネントの候補ペアを形成します。 | |
| oリモート候補をそのコンポーネントの提供者のデフォルトの宛先と等しく設定する（たとえば、RTPのmおよびc行の内容、RTCPのa = rtcp属性）。 | |
| oオファーのa = remote-candidates属性で、同じコンポーネントのトランスポートアドレスに等しいローカル候補を設定します。 | |
| 次に、それらの候補をメディアストリームの有効なリストに配置します。そのメディアストリームのICE処理の状態は、完了に設定されます。 | |
| さらに、エージェントが制御していると信じていたが、オファーにリモート候補属性が含まれていた場合、両方のエージェントが制御していると信じます。この場合、両方が同じ時間に更新されたオファーを送信していました。ただし、オファー/アンサー交換を伝送するシグナリングプロトコルはこのグレア状態を解決しているため、ピアがオファーを送信する前にオファーを受信することにより、1人のエージェントが常に「勝者」になります。勝者は統制の役割を引き受けるため、敗者（このセクションで検討中の回答者）はその役割を統制に変更する必要があります。その結果、セクション8.2.2のルールに基づいてエージェントが制御していたため、エージェントが更新されたオファーを送信しようとした場合、それはもはや必要ではありません。 | |
| 潜在的な役割の変更、有効リストの変更、および状態の変更に加えて、回答の構築は、セクション9.1.3で説明されているオファーの構築と同じように実行されます。 | |
| 9.3。チェックリストと有効リストの更新 | |
| 9.3.1。完全な実装の手順 | |
| 9.3.1.1。ICE再起動 | |
| エージェントは、再起動の前に、以前に選択されたペアと呼ばれる、メディアストリームの各コンポーネントの有効リスト内で最も優先度の高い候補ペアを記憶しなければなりません。セクション11.1で説明されているように、エージェントはこれらのペアを使用してメディアを送信し続けます。これらの宛先が記録されると、エージェントは有効リストとチェックリストをフラッシュし、セクション5.7で説明されているようにチェックリストとその状態を再計算する必要があります。 | |
| 9.3.1.2。新しいメディアストリーム | |
| オファー/アンサー交換が新しいメディアストリームを追加した場合、エージェントはセクション5.7で説明されているように、そのメディアの新しいチェックリスト（およびもちろん開始する空の有効なリスト）を作成する必要があります。9.3.1.3。削除されたメディアストリーム | |
| オファー/アンサー交換がメディアストリームを削除した場合、またはアンサーが提供されたメディアストリームを拒否した場合、エージェントはそのメディアストリームの有効なリストをフラッシュする必要があります。そのメディアストリームで進行中のSTUNトランザクションを終了する必要があります。エージェントは、そのメディアストリームのチェックリストを削除し、保留中の通常のチェックをキャンセルする必要があります。 | |
| 9.3.1.4。既存のメディアストリームを継続するICE | |
| 有効なリストは、ICEが再起動されない限り、更新されたオファー/アンサー交換の影響を受けません。 | |
| エージェントがそのメディアストリームの実行状態にある場合、チェックリストは更新されます（状態が完了した場合、チェックリストは無関係です）。そのために、エージェントはセクション5.7で説明されている手順を使用してチェックリストを再計算します。新しいチェックリストのペアが前のチェックリストにもあり、その状態が待機中、進行中、成功、または失敗の場合、その状態はコピーされます。それ以外の場合、状態はFrozenに設定されます。 | |
| アクティブなチェックリストがない場合（各チェックリストのペアが凍結されていることを意味します）、フルモードエージェントは最初のメディアストリームのチェックリストの最初のペアを待機に設定し、他のすべての状態を設定します同じコンポーネントIDのチェックリスト内のペアと同じ基盤を使用して待機します。 | |
| 次に、エージェントは最高の優先度のペアから順に各チェックリストを調べます。ペアの状態がSucceededで、コンポーネントIDが1の場合、コンポーネントIDが1でない同じ基盤を持つ同じチェックリスト内のすべてのフローズンペアの状態はWaitingに設定されます。特定のチェックリストについて、Succeeded状態のそのメディアストリームの各コンポーネントのペアがある場合、エージェントは他のすべてのメディアストリームの最初のコンポーネント（したがって異なるチェックリスト）のすべてのフローズンペアの状態を移動します同じ基盤を待っています。 | |
| 9.3.2。Lite実装の手順 | |
| ICEがメディアストリームに対して再起動する場合、エージェントはそのメディアストリームの新しい有効なリストを開始する必要があります。前の選択されたペアと呼ばれる、メディアストリームの各コンポーネントの前の有効なリストのペアを記憶し、セクション11.1で説明されているようにメディアを送信し続ける必要があります。各メディアストリームのICE処理の状態は実行中に変更する必要があり、ICE処理の状態は実行中に変更する必要があります。 | |
| 10.キープアライブ | |
| すべてのエンドポイントは、メディアセッションごとにキープアライブを送信する必要があります。これらのキープアライブは、メディアセッションのためにNATバインディングを有効に保つ目的に役立ちます。これらのキープアライブは、メディアストリームが現在非アクティブ、sendonly、recvonly、またはsendrecvであるかどうか、および帯域幅属性の存在または値に関係なく送信されなければなりません。セッションでICEがまったく使用されていない場合でも、これらのキープアライブを送信する必要があります。キープアライブは、ピアでサポートされている形式を使用して送信する必要があります。ICEエンドポイントは、UDPストリームのSTUNベースのキープアライブを許可するため、エージェントが完全なICE実装であり、ICEをサポートするピアと通信する場合（ライトまたはフル）、STUNキープアライブを使用する必要があります。エージェントは、各メディアセッションのa = candidate属性が存在することにより、ピアがICEをサポートしていると判断できます。ピアがICEをサポートしていない場合、キープアライブのパケット形式の選択はローカル実装の問題です。実際のメディアコンテンツがなくてもパケットを簡単に送信できる形式を推奨します。この目標を容易に満たすフォーマットの例は、RTP No-Op [NO-OP-RTP]であり、両側がそれをサポートする場合、RTPコンフォートノイズ[RFC3389]です。ピアがキープアライブに特に適した形式をサポートしていない場合、エージェントは、不正なバージョン番号、またはピアによって破棄されるようなエラーの他の形式でRTPパケットを送信する必要があります。この目標を容易に満たすフォーマットの例は、RTP No-Op [NO-OP-RTP]であり、両側がそれをサポートする場合、RTPコンフォートノイズ[RFC3389]です。ピアがキープアライブに特に適した形式をサポートしていない場合、エージェントは、不正なバージョン番号、またはピアによって破棄されるようなエラーの他の形式でRTPパケットを送信する必要があります。この目標を容易に満たすフォーマットの例は、RTP No-Op [NO-OP-RTP]であり、両側がそれをサポートする場合、RTPコンフォートノイズ[RFC3389]です。ピアがキープアライブに特に適した形式をサポートしていない場合、エージェントは、不正なバージョン番号、またはピアによって破棄されるようなエラーの他の形式でRTPパケットを送信する必要があります。 | |
| ICEがTr秒のメディアコンポーネントに使用している候補ペア（パケットにコンポーネント（RTPまたはRTCP）および以前のキープアライブに定義されたものが含まれる）で送信されたパケットがなかった場合、エージェントはそのペアでキープアライブを生成する必要があります。Trは設定可能であるべきであり（SHOULD）、デフォルトは15秒です。Trは15秒未満に設定してはなりません。あるいは、エージェントが介在するNATのバインディングライフタイムを動的に検出する方法を持っている場合、その値を使用してTrを決定できます。より制御されたネットワーク環境でICEを展開する管理者は、Trを環境内で可能な限り長い期間に設定する必要があります。 | |
| キープアライブにSTUNが使用されている場合、STUNバインディング表示が使用されます[RFC5389]。指示は認証メカニズムを利用してはなりません。逆多重化を支援するためにFINGERPRINT属性を含むべきであるが、他の属性を含むべきではない。NATバインディングを維持するためだけに使用されます。バインディング表示は、メディアに使用されている同じローカルおよびリモート候補を使用して送信されます。キープアライブにはバインディング指示が使用されますが、接続チェックも受信するようにエージェントを準備する必要があります。接続性チェックが受信されると、[RFC5389]で説明されているように応答が生成されますが、それ以外の場合はICE処理に影響はありません。 | |
| エージェントは、ICEがメディアでの使用候補を選択するか、メディアが流れ始めるか、どちらか早い方でキープアライブ処理を開始しなければなりません。キープアライブは、セッションが終了するか、メディアストリームが削除されると終了します。 | |
| 11.メディアの取り扱い | |
| 11.1。メディアの送信 | |
| メディアを送信する手順は、完全実装と簡易実装で異なります。 | |
| 11.1.1。完全な実装の手順 | |
| エージェントは常に、選択した候補ペアと呼ばれる候補ペアを使用してメディアを送信します。エージェントは、選択したペアのリモート候補にメディアを送信し（パケットの宛先アドレスとポートをそのリモート候補に等しく設定します）、選択したペアのローカル候補からメディアを送信します。ローカル候補者がサーバーまたはピアの再帰である場合、メディアはベースから発信されます。リレーされた候補者から送信されたメディアは、[RFC5766]で定義された手順を使用して、そのTURNサーバーを介してベースから送信されます。 | |
| ローカル候補者がリレー候補者である場合、エージェントがTURNサーバー上でリモート候補者へのチャネルを作成することをお勧めします。これは、[RFC5766]のセクション11で定義されているチャネル作成の手順を使用して行われます。 | |
| メディアストリームのコンポーネント用に選択されたペアは次のとおりです。 | |
| oそのメディアストリームのチェックリストの状態が実行中で、ICEの再起動のためにそのコンポーネントに対して以前に選択されたペアがない場合は空 | |
| oそのメディアストリームのチェックリストの状態が実行中で、ICEの再起動によりそのコンポーネントの以前に選択されたペアがあった場合、メディアストリームのコンポーネントに対して以前に選択されたペアに等しい | |
| oチェックリストの状態がCompletedの場合、有効なリスト内のそのコンポーネントの最も優先度の高い指名ペアに等しい | |
| メディアストリームの少なくとも1つのコンポーネントの選択されたペアが空の場合、エージェントはそのメディアストリームのコンポーネントのメディアを送信してはなりません。メディアストリームの各コンポーネントの選択されたペアに値がある場合、エージェントはそのメディアストリームのすべてのコンポーネントのメディアを送信できます。 | |
| メディアストリームのコンポーネント用に選択されたペアは、最新のオファー/アンサー交換の同じコンポーネントのデフォルトペアとは異なる場合があります。この場合、デフォルトのペアではなく、選択したペアがメディアに使用されます。ICEが最初に完了したときに、選択されたペアがデフォルトペアと一致しない場合、制御エージェントは更新されたオファー/アンサー交換を送信して、この不均衡を解消します。ただし、更新されたオファーが到着するまで、一致するものはありません。さらに、非常にまれなケースでは、更新されたオファー/アンサーのデフォルトの候補は一致しません。 | |
| 11.1.2。Lite実装の手順 | |
| ライトの実装は、そのメディアストリームの各コンポーネントの候補ペアを含む有効なリストがあるまで、メディアを送信してはなりません。それが起こると、エージェントはメディアパケットの送信を開始できます。そのために、ペアのリモート候補にメディアを送信し（パケットの宛先アドレスとポートをそのリモート候補に等しく設定し）、ローカル候補から送信します。 | |
| 11.1.3。すべての実装の手順 | |
| ICEは、ジッタバッファ適応メカニズムと相互作用します。RTPストリームは1つの候補の使用を開始し、別の候補に切り替えることができますが、これはICEではめったに起こりません。新しい候補では、RTPパケットが、ネットワークを通る異なるパス（異なる遅延特性を持つパス）を取る可能性があります。以下で説明するように、メディアパケットの送信元または宛先アドレスに変更がある場合、エージェントはジッタバッファを再調整することが推奨されます。さらに、多くのオーディオコーデックは、ジッタバッファアダプテーションの目的で、マーカービットを使用してトークスパートの開始を通知します。このようなコーデックの場合、エージェントがメディアの送信を1つの候補ペアから別の候補ペアに切り替えるときに、送信者がマーカービット[RFC3550]を設定することが推奨されます。 | |
| 11.2。受信メディア | |
| ICE実装は、最新のオファー/アンサー交換でそのコンポーネントに提供された候補の各コンポーネントでメディアを受信するように準備する必要があります（RTPの場合、候補が両方に提供された場合、RTPとRTCPの両方が含まれます）。 | |
| これは推奨され、そのエージェントは、エージェントがそのジッタバッファを再調整することを、特定のメディアストリームのための新しい送信元または宛先IPアドレスとRTPパケットを受信したとき。 | |
| RFC 3550 [RFC3550]は、同期ソース（SSRC）の衝突とループを検出するためのセクション8.2のアルゴリズムについて説明しています。これらのアルゴリズムは、部分的には、同じSSRCで異なるソーストランスポートアドレスを見ることに基づいています。ただし、ICEを使用すると、メディアストリームが候補間で切り替わるときにこのような変更が発生することがあります。エージェントは、メディア送信を進めるSTUN交換の結果として、メディアストリームが同じピアからのものであることを判別できます。したがって、ソーストランスポートアドレスに変更があるが、メディアパケットが同じピアエージェントから送信されている場合、これはSSRCコリジョンとして扱われるべきではありません。 | |
| 12. SIPでの使用 | |
| 12.1。レイテンシーガイドライン | |
| ICEでは、エンドポイント間で行われる一連のSTUNベースの接続チェックが必要です。これらのチェックは、回答の生成時に回答者から始まり、回答を受け取った提供者から始まります。これらのチェックは完了するのに時間がかかる場合があるため、オファーおよびアンサーで使用するメッセージの選択は、知覚されるユーザーの待ち時間に影響を与える可能性があります。特に興味深いのは、2つのレイテンシの数値です。これらは、ピックアップ後の遅延とダイヤル後の遅延です。ピックアップ後の遅延とは、ユーザーが「電話に応答」してから発話が発信者に配信されるまでの時間のことです。ダイヤル後遅延とは、ユーザーがユーザーの宛先アドレスを入力してから、着呼側の電話の呼び出しを正常に開始した結果としてリングバックが開始されるまでの時間を指します。 | |
| 2つのケースが考えられます。最初のINVITEにオファーが存在するケースと、応答にあるケースです。 | |
| 12.1.1。INVITEで提供 | |
| ダイヤル後の遅延を減らすために、発信者が実際に最初のINVITEを送信する前に候補者の収集を開始することをお勧めします。これは、キーパッドでのアクティビティや電話がオフフックになるなど、通話が保留中であることをユーザーインターフェイスが示すときに開始できます。 | |
| INVITEリクエストでオファーが受信された場合、回答者はオファーの受信時に候補者の収集を開始する必要があり（SHOULD）、そのプロセスが完了すると暫定応答で回答を生成します。ICEでは、SDPを使用した暫定応答を確実に送信する必要があります。これは、既存の暫定応答確認（PRACK）メカニズム[RFC3262]を通じて、またはICEに固有の最適化を通じて実行できます。この最適化により、1つ以上のメディアストリームのICE処理を開始するSDP回答を含む暫定応答をRFC 3262なしで確実に送信できます。これを行うために、エージェントはRFC 3262で説明されている指数バックオフタイマーで暫定応答を再送信します。再送信は、そのSDPでシグナリングされたメディアストリームの1つに対するSTUNバインディング要求の受信（バインディング要求の受信が提供者が回答を受信したことを示すため）または2xx応答の回答の送信で停止しなければなりません（MUST）。ピアエージェントがライトの場合、STUNバインディング要求はありません。そのような場合、エージェントは18xを4回送信した後、18xの再送信を停止しなければなりません（ピアが18xを受信しなくても、ICEは実際に機能しますが、経験により、送信はミドルボックスとファイアウォールトラバーサルにとって重要であることが示されています）。最後の再送信の前にバインディング要求が受信されない場合、エージェントはセッションが終了したとは見なしません。暫定応答が確実に配信されるという事実にもかかわらず、エージェントが更新されたオファーまたはアンサーをいつ送信できるかに関するルールは、RFC 3262で指定されたものから変更されません。2xxが送信された後にのみ、更新されたオファー/アンサー交換が発生します。両方のエージェントがPRACKをサポートする場合、この最適化は使用すべきではありません。最適化は、ICE処理を開始する回答を運ぶ暫定応答に非常に固有であることに注意してください。1xxの信頼性のための一般的な手法ではありません。最適化は、ICE処理を開始する回答を運ぶ暫定応答に非常に固有であることに注意してください。1xxの信頼性のための一般的な手法ではありません。最適化は、ICE処理を開始する回答を運ぶ暫定応答に非常に固有であることに注意してください。1xxの信頼性のための一般的な手法ではありません。 | |
| あるいは、エージェントは200 OKまで回答の送信を遅らせることができます。ただし、これによりユーザーエクスペリエンスが低下するため、お勧めしません。 | |
| 回答が送信されると、エージェントは接続チェックを開始する必要があります。メディアストリームの各コンポーネントの候補ペアが有効なリストに入ると、回答者はそのメディアストリームでメディアの送信を開始できます。 | |
| ただし、この時点より前に、発信者に向けて送信する必要のあるメディア（SIPアーリーメディア[RFC3960]など）を送信してはなりません。このため、実装は、各メディアストリームの各コンポーネントの候補が有効なリストに入るまで、着信者へのアラートを遅らせる必要があります。PSTNゲートウェイの場合、これはPSTNへのセットアップメッセージがこの時点まで遅延することを意味します。これを行うと、ダイヤル後の遅延が増加しますが、「ゴーストリング」を排除する効果があります。ゴーストリングとは、着信側が電話の呼び出し音を聞いた後、ピックアップしたものの、何も聞こえず、聞こえない場合です。この手法は、ローカライズされた決定であるため、前提条件[RFC3312]のサポートや使用を必要とせずに機能します。また、メディアの単一パケットがクリップされないことを保証するという利点もあります。そのため、ピックアップ後の遅延はゼロです。エージェントがこの方法でローカルアラートを遅延することを選択した場合、アラートが開始されると180応答を生成する必要があります。 | |
| 12.1.2。応答で提供 | |
| オファーがINVITEにあり、回答が暫定応答または200 OK応答、あるいはその両方で使用されることに加えて、ICEはオファーが応答に表示される場合に機能します。サードパーティのコール制御[RFC3725]で一般的なこのような場合、ICEエージェントは、信頼できる暫定応答（RFC 3262を使用する必要があります）でオファーを生成する必要があり、INVITEの受信時にユーザーに警告しません。答えはPRACKで届きます。これにより、アラートの前にICE処理が行われるため、コールセットアップの遅延が増加しますが、ピックアップ後の遅延は発生しません。ICEが完了すると、呼び出し先はユーザーに警告し、ユーザーが応答すると200 OKを生成できます。200 OKには、オファー/アンサー交換が完了したため、SDPは含まれません。 | |
| または、エージェントは代わりに2xxにオファーを配置することができます（この場合、応答はACKで受信されます）。これが発生すると、呼び出し先はINVITEの受信時にユーザーに警告し、ICEの交換はユーザーが応答した後にのみ行われます。これにより、コールセットアップの遅延が削減されますが、ピックアップ後の大幅な遅延とメディアクリッピングが発生する可能性があります。 | |
| 12.2。SIPオプションタグとメディア機能タグ | |
| [RFC5768]は、ICEで使用するためのSIPオプションタグとメディア機能タグを指定します。SIPを使用するICE実装はこの仕様をサポートする必要があります（SHOULD）。 | |
| 12.3。フォークとの相互作用 | |
| ICEはフォークと非常によく相互作用します。実際、ICEは分岐に関連する問題の一部を修正します。ICEがなければ、コールが分岐し、発信者が複数の着信メディアストリームを受信すると、どのメディアストリームがどの着信者に対応するかを判断できません。 | |
| ICEでは、この問題は解決されています。メディアの送信前に発生する接続性チェックは、ユーザー名フラグメントを運びます。ユーザー名フラグメントは、特定の呼び出し先に関連付けられます。接続チェックと同じ候補ペアに到着する後続のメディアパケットは、その同じ呼び出し先に関連付けられます。したがって、呼び出し元は、応答を受信している限り、この相関を実行できます。 | |
| 12.4。前提条件との相互作用 | |
| RFC 3312 [RFC3312]およびRFC 4032 [RFC4032]で定義されているQuality of Service（QoS）の前提条件は、オファー/アンサーのメディアのデフォルトターゲットとしてリストされているトランスポートアドレスにのみ適用されます。ICEがメディアを受信するトランスポートアドレスを変更すると、この変更は更新されたオファーに反映され、ICEの選択に合わせてメディアのデフォルトの宛先が変更されます。そのため、他のre-INVITEと同様に表示され、RFC 3312および4032で完全に処理されます。RFC3312および4032は、「バックグラウンドで」発生するICEネゴシエーションによりメディアの宛先が変更されるという事実に関係なく適用されます。 | |
| 実際、エージェントは、チェックが完了し、メディアに使用される候補ペアを選択するまで、QoS前提条件が満たされていることを示すべきではありません。 | |
| ICEは、接続の前提条件（SDP-PRECON）との（意図的な）対話も行います。それらの相互作用はそこで説明されています。セクション12.1で説明されている手順は、[SDP-PRECON]の明示的な前提条件によって提供される機能よりも機能性は低いものの、独自のタイプの「前提条件」を記述していることに注意してください。 | |
| 12.5。サードパーティコール制御との相互作用 | |
| ICEは、[RFC3725]で説明されているように、フローI、III、およびIVで動作します。Flow Iは、コントローラーがICEをサポートまたは認識せずに動作します。フローIVは、コントローラーが変更せずにICE属性を通過する限り機能します。Flow IIは、基本的にICEと互換性がありません。各エージェントは自分自身が回答者であると信じるため、再招待を生成しません。 | |
| RFC 3725のセクション7で説明されているように、継続操作のフローでは、サポートするためにICE実装の追加動作が必要です。特に、エージェントがオファーを含まないダイアログ中の再招待を受信した場合、メディアストリームごとにICEを再起動し、新しい候補者を収集するプロセスを実行する必要があります。さらに、その候補のリストには、現在メディアに使用されているものを含める必要があります。 | |
| 13. ANATとの関係 | |
| RFC 4091 [RFC4091]、SDPグループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス、およびRFC 4092 [RFC4092]、SIPでのその使用法は、エージェントがメディアに対してIPv4とIPv6の両方をサポートできることを示すメカニズムを定義しますストリーム。2つのm行（v4用とv6用）を含めることでそうします。これはICEに似ており、エージェントが候補属性を使用して複数のトランスポートアドレスを示すことができます。ただし、ANATは、ICEが使用する動的な接続チェックではなく、静的な選択に依存して選択肢を選択します。 | |
| この仕様では、RFC 4091とRFC 4092が非推奨になりました。代わりに、デュアルスタックのサポートを希望するエージェントはICEを利用します。 | |
| 14.拡張性に関する考慮事項 | |
| この仕様は、セッション内の両方のエージェントがメディア用に選択された候補ペアのセットに到達するための調整方法について、非常に具体的な選択を行います。タイマーの調整などの単純な変更であれ、優先アルゴリズムの改良などの大きな変更であれ、将来の仕様ではこれらのアルゴリズムを変更することが予想されます。このような変更が行われる場合、セッション内の2つのエージェント間の相互運用性を提供することが重要です。 | |
| まず、ICEはa = ice-options SDP属性を提供します。ICEの各拡張または変更は、トークンに関連付けられています。そのような拡張または変更をサポートするエージェントがオファーまたはアンサーを生成する場合、この属性にその拡張のトークンを含めなければなりません。これにより、各サイドは相手が何をしているかを知ることができます。エージェントがICE拡張または変更をサポートしない場合、この属性は存在してはなりません。 | |
| 現時点では、これらのオプションタグに対してIANAレジストリまたは登録手順は定義されていません。執筆時点では、ICEの変更と拡張がレジストリを保証するのに十分一般的であるかどうかは不明です。 | |
| 相互運用性を実現する際の複雑さの1つは、ICEが両方のエージェントで実行される分散アルゴリズムに依存して、合意された候補ペアのセットに収束することです。2つのエージェントが異なるアルゴリズムを実行している場合、同じ候補ペアでの収束を保証することは困難です。セクション8で説明した定期的な指名手順では、選択アルゴリズムを制御エージェントに完全に委任することにより、一部の緊密な調整を排除します。その結果、制御エージェントが知らないオプションをサポートするピアと通信しているとき、エージェントは通常の指名アルゴリズムを実行しなければなりません。定期的な指名を使用すると、両方のエージェントが異なるペアの優先順位付けアルゴリズムを使用する場合でも、ICEは完全に収束します。このような収束の鍵の1つは、トリガーチェックです。これにより、指定されたペアが両方のエージェントによって検証されます。したがって、今後のICEの機能強化では、トリガーされたチェックを保持する必要があります。 | |
| ICEは、RTPを超える他のメディアストリームや、UDPを超えるトランスポートプロトコルにも拡張可能です。非RTPメディアストリーム用のICEの拡張機能では、利用するコンポーネントの数を指定し、最も重要なコンポーネントIDの1からコンポーネントIDを割り当てる必要があります。新しいトランスポートプロトコルの仕様では、ICE処理のさまざまな手順がUDPとどのように異なるかを定義する必要があります。15.文法 | |
| この仕様では、「候補」、「リモート候補」、「アイスライト」、「アイスミスマッチ」、「アイスufrag」、「アイスpwd」、「アイスオプション」という7つの新しいSDP属性を定義しています。属性。 | |
| 15.1。「候補」属性 | |
| 候補属性は、メディアレベルの属性のみです。接続チェックに使用できる候補のトランスポートアドレスが含まれています。 | |
| この属性の構文は、RFC 5234 [RFC5234]で定義されているように、拡張BNFを使用して定義されます。 | |
| 候補属性= "候補" "："基盤SPコンポーネントID SPトランスポートSP優先度SP接続アドレスSP; RFC 4566ポートから; RFC 4566 SPからのポートcand-type [SP rel-addr] [SP rel-port] *（SP拡張子-att-name SP拡張子-att-value） | |
| Foundation = 1 * 32ice-char component-id = 1 * 5DIGIT transport = "UDP" / transport-extension transport-extension = token; RFC 3261からpriority = 1 * 10DIGIT cand-type = "typ" SP候補タイプ候補タイプ= "host" / "srflx" / "prflx" / "relay" /トークンrel-addr = "raddr" SP接続-アドレスrel-port = "rport" SPポートextension-att-name = byte-string; RFC 4566からextension-att-value = byte-string ice-char = ALPHA / DIGIT / "+" / "/" | |
| この文法は、候補者に関する主な情報であるIPアドレス、ポートおよびトランスポートプロトコル、およびそのプロパティ：基盤、コンポーネントID、優先度、タイプ、および関連するトランスポートアドレスをエンコードします。 | |
| <connection-address>：RFC 4566 [RFC4566]から取得されます。これは候補のIPアドレスであり、IPv4アドレス、IPv6アドレス、および完全修飾ドメイン名（FQDN）を許可します。このフィールドを解析するとき、エージェントは値にコロンが存在することでIPv4アドレスとIPv6アドレスを区別できます-コロンの存在はIPv6を示します。エージェントは、サポートまたは認識されていないIPアドレスバージョンの候補を含む候補行を無視する必要があります。IPアドレスを使用する必要がありますが、IPアドレスの代わりにFQDNを使用することができます。その場合、a = candidate属性にFQDNを含むオファーまたはアンサーを受信すると、最初にAAAAレコードを使用してFQDNがDNSで検索され（エージェントがIPv6をサポートしている場合）、結果が見つからないか、エージェントがAを使用してIPv4のみをサポートします。 | |
| <port>：RFC 4566 [RFC4566]からも取得されます。候補者のポートです。 | |
| <transport>：候補のトランスポートプロトコルを示します。この仕様はUDPのみを定義しています。ただし、TCPやDatagram Congestion Control Protocol（DCCP）[RFC4340]など、将来のトランスポートプロトコルをICEで使用できるように拡張性が提供されます。 | |
| <foundation>：1〜32個の<ice-char>で構成されます。これは、同じタイプで、同じベースを共有し、同じSTUNサーバーに由来する2つの候補に対して同等の識別子です。この基盤は、フローズンアルゴリズムでICEパフォーマンスを最適化するために使用されます。 | |
| <component-id>：1〜256の正の整数で、これが候補であるメディアストリームの特定のコンポーネントを識別します。1から開始し、特定の候補のコンポーネントごとに1ずつ増加する必要があります。RTPに基づくメディアストリームの場合、実際のRTPメディアの候補はコンポーネントIDが1でなければならず、RTCPの候補はコンポーネントIDが2でなければなりません。複数のコンポーネントを必要とする他のタイプのメディアストリームは、コンポーネントからコンポーネントID。ICEを新しいメディアストリームに拡張する方法については、セクション14を参照してください。 | |
| <優先度>：1から（2 ** 31-1）までの正の整数です。 | |
| <cand-type>：候補のタイプをエンコードします。この仕様では、それぞれ、ホスト、サーバーの再帰、ピアの再帰、およびリレー候補の値「ホスト」、「srflx」、「prflx」、および「リレー」を定義しています。候補タイプのセットは、将来拡張可能です。 | |
| <rel-addr>および<rel-port>：候補に関連するトランスポートアドレスを伝達します。診断およびその他の目的に役立ちます。<rel-addr>および<rel-port>は、サーバー反射候補、ピア反射候補、およびリレー候補に存在しなければなりません。候補がサーバーまたはピアの再帰候補である場合、<rel-addr>および<rel-port>は、そのサーバーまたはピアの再帰候補のベースと等しくなります。候補がリレーされる場合、<rel-addr>と<rel-port>は、そのリレーされた候補をクライアントに提供したAllocate応答のマッピングアドレスと等しくなります（その目的については、付録B.3を参照してください）。候補がホスト候補である場合、<rel-addr>と<rel-port>は省略されなければなりません。 | |
| 候補属性自体を拡張できます。文法により、属性の最後に新しい名前/値のペアを追加できます。実装は、理解できない名前/値のペアを無視しなければなりません。 | |
| 15.2。「リモート候補」属性 | |
| 「remote-candidates」属性の構文は、RFC 5234 [RFC5234]で定義されているように、拡張BNFを使用して定義されます。リモート候補属性は、メディアレベルの属性のみです。 | |
| remote-candidate-att = "remote-candidates" "：" remote-candidate 0 *（SP remote-candidate）remote-candidate =コンポーネントID SP接続アドレスSPポート | |
| 属性には、各コンポーネントの接続アドレスとポートが含まれます。コンポーネントの順序は関係ありません。ただし、メディアストリームの各コンポーネントには値が存在する必要があります。この属性は、完了したメディアストリームの制御エージェントによるオファーに含まれている必要があり、他の場合には含まれてはなりません。 | |
| 15.3。「ice-lite」および「ice-mismatch」属性 | |
| フラグである「ice-lite」および「ice-mismatch」属性の構文は次のとおりです。 | |
| ice-lite = "ice-lite" ice-mismatch = "ice-mismatch" | |
| 「ice-lite」はセッションレベルの属性のみであり、エージェントがライト実装であることを示します。「ice-mismatch」はメディアレベルの属性のみであり、回答内に存在する場合、対応する候補属性を持たないメディアコンポーネントのデフォルトの宛先でオファーが到着したことを示します。 | |
| 15.4。「ice-ufrag」および「ice-pwd」属性 | |
| 「ice-ufrag」および「ice-pwd」属性は、メッセージの整合性のためにICEが使用するユーザー名フラグメントとパスワードを伝えます。構文は次のとおりです。 | |
| ice-pwd-att = "ice-pwd" "："パスワードice-ufrag-att = "ice-ufrag" "：" ufragパスワード= 22 * 256ice-char ufrag = 4 * 256ice-char | |
| 「ice-pwd」および「ice-ufrag」属性は、セッションレベルまたはメディアレベルで表示できます。両方に存在する場合、メディアレベルの値が優先されます。したがって、セッションレベルの値は、メディアレベルの値で上書きされない限り、事実上すべてのメディアストリームに適用されるデフォルトです。セッションに存在するかメディアレベルに存在するかにかかわらず、各メディアストリームにはice-pwdおよびice-ufrag属性がなければなりません。2つのメディアストリームに同一のice-ufragがある場合、それらには同一のice-pwdがなければなりません。 | |
| ice-ufragおよびice-pwd属性は、セッションの開始時にランダムに選択する必要があります。ice-ufrag属性は少なくとも24ビットのランダム性を含まなければならず（MUST）、ice-pwd属性は少なくとも128ビットのランダム性を含まなければなりません（MUST）。これは、Ice-ufrag属性の長さが少なくとも4文字で、Ice-pwdの長さが少なくとも22文字であることを意味します。これらの属性の文法では、文字ごとに6ビットのランダム性が許可されるためです。属性は、それぞれ4文字と22文字よりも長い場合があり、それぞれ最大256文字です。上限により、実装でのバッファーのサイズ設定が可能になります。上限が大きいため、時間の経過とともにランダム性の量を増やすことができます。 | |
| 15.5。「ice-options」属性 | |
| 「ice-options」属性は、セッションレベルの属性です。エージェントがサポートするオプションを識別する一連のトークンが含まれています。その文法は次のとおりです。 | |
| ice-options = "ice-options" "：" ice-option-tag 0 *（SP ice-option-tag）ice-option-tag = 1 * ice-char | |
| 16. TaおよびRTOの設定 | |
| ICEの収集フェーズ（セクション4.1.1）およびICEが接続性チェックを実行している間（セクション7）、エージェントはSTUNおよびTURNトランザクションを送信します。これらのトランザクションは、Taミリ秒ごとに1つのペースで処理され、特定のRTOを使用します。このセクションでは、TaおよびRTOの値の計算方法について説明します。この計算は、ICEがリアルタイムメディアストリーム（RTPなど）または他の何かで使用されているかどうかによって異なります。既知の最大帯域幅を持つストリームにICEを使用する場合、セクション16.1の計算に従って、ICE交換をレート制御できます（MAY）。他のすべてのストリームについては、セクション16.2の計算に従う必要があります。 | |
| 16.1。RTPメディアストリーム | |
| RTOおよびTaの値は、ICE処理の存続期間中に変化します。値の1つのセットは収集フェーズで適用され、もう1つのセットは接続性チェックに適用されます。 | |
| Taの値は構成可能である必要があり（SHOULD）、デフォルト値は次のとおりです（SHOULD）。 | |
| 各メディアストリームiについて： | |
| Ta_i =（stun_packet_size / rtp_packet_size）* rtp_ptime | |
| 1 Ta = MAX（20ms、-------------------）k ---- \ 1> ------ / Ta_i ---- i = 1 | |
| ここで、kはメディアストリームの数です。収集フェーズでは、エージェントがオファーまたはアンサーで示したメディアストリームの数に基づいてTaが計算され、RTPパケットサイズとRTP ptimeは各メディアストリームの最も好ましいコーデックの値です。オファーと回答が交換されると、エージェントはTaを再計算して接続チェックのペースを調整します。その場合、Taの値は、セッションで実際に使用されるメディアストリームの数に基づいており、RTPパケットサイズとRTP ptimeは、エージェントが送信する最も好ましいコーデックのものです。 | |
| さらに、[RFC5389]で定義されたSTUNトランザクションの再送信タイマー、RTOは設定可能であるべきであり（SHOULD）、収集段階では、デフォルトのSHOULDが必要です： | |
| RTO = MAX（100ms、Ta *（ペアの数）） | |
| ここで、ペアの数は、STUNまたはTURNサーバーとの候補のペアの数を指します。 | |
| 接続性チェックの場合、RTOは構成可能である必要があり（SHOULD）、デフォルトは次のようになっている必要があります。 | |
| RTO = MAX（100ms、Ta * N *（Num-Waiting + Num-In-Progress）） | |
| Num-Waitingは、Waiting状態のチェックリスト内のチェックの数であり、Num-In-Progressは、In-Progress状態のチェックの数です。待機中および進行中の状態のチェック数が変わると、RTOはトランザクションごとに異なることに注意してください。 | |
| これらの公式は、STUNトランザクションがメディアと同じレートでペースを調整することを目的としています。これにより、メディアをサポートするために必要な同じネットワーク条件の下でICEが適切に機能することが保証されます。追加の議論と動機については、付録B.1を参照してください。このペースのため、すべてのサーバーの再帰候補およびリレー候補を取得するには、ある程度の時間がかかります。実装はこれを行うのに必要な時間を認識し、アプリケーションに時間の予算が必要な場合は、収集する候補者の数を制限する必要があります。 | |
| この式により、エージェントは、再送信を実行する前に、接続チェックごとに最初のパケットを送信するという動作になります。これは、RTO（再送信間隔を表す）の式で見ることができます。これらの式は、実行されるチェックの数であるNに比例します。この結果、ICEは一定のレートを維持しますが、パケット損失の影響を受けやすくなります。接続性チェックの最初の単一パケットの損失により、そのペアの検証に時間がかかる可能性が高く、代わりに、優先順位の低いチェック（ただし、パケット損失がなかったもの）の可能性がはるかに高くなります最初に完了します。これにより、ICEのパフォーマンスが最適化されず、優先度の高いペアよりも優先度の低いペアが選択されます。実装者はこの結果に注意する必要があり、 | |
| 16.2。非RTPセッション | |
| ICEを使用して、リアルタイムではない何らかの種類のセッションを確立し、ICEが展開されているネットワークで動作することがわかっている固定レートが関連付けられていない場合、TaとRTOはより保守的な値に戻ります。Taは構成可能でなければならず（SHOULD）、デフォルトは500ミリ秒である必要があり（SHOULD）、500ミリ秒未満に構成することはできません（MUST NOT）。 | |
| さらに、STUNトランザクションの再送信タイマーRTOは構成可能である必要があり、収集フェーズ中にデフォルトのRTO = MAX（500ミリ秒、Ta *（ペアの数））を設定する必要があります。 | |
| ここで、ペアの数は、STUNまたはTURNサーバーとの候補のペアの数を指します。 | |
| 接続性チェックの場合、RTOは構成可能である必要があり（SHOULD）、デフォルトは次のようになっている必要があります。 | |
| RTO = MAX（500ms、Ta * N *（Num-Waiting + Num-In-Progress）） | |
| 17.例 | |
| この例は、図8の単純化されたトポロジに基づいています。 | |
| + ----- + | | | STUN | | Srvr | + ----- + | + --------------------- + | | | インターネット| | | | | + --------------------- + | | | | + --------- + | | NAT | | + --------- + | | | | | | | + ----- + + ----- + | | | | | L | | R | | | | | + ----- + + ----- + | |
| 図8：トポロジの例 | |
| 2つのエージェント、LとRがICEを使用しています。どちらもフルモードICE実装であり、制御時に積極的な指名を使用します。両方のエージェントには、単一のIPv4アドレスがあります。エージェントLの場合、プライベートアドレススペース[RFC1918]で10.0.1.1であり、エージェントRの場合、パブリックインターネット上の192.0.2.1です。両方とも同じSTUNサーバーで構成されます（簡単にするためにこの例に示されていますが、実際にはエージェントは同じSTUNサーバーを使用する必要はありません）。この例では、TURNサーバーは使用されません。エージェントLはNATの背後にあり、エージェントRはパブリックインターネット上にあります。NATには、エンドポイントに依存しないマッピングプロパティとアドレス依存のフィルタリングプロパティがあります。NATのパブリック側のIPアドレスは192.0.2.3です。 | |
| 理解を容易にするため、トランスポートアドレスはニーモニック名を持つ変数を使用してリストされます。名前の形式はentity-type-seqnoです。ここで、entityは、トランスポートアドレスが存在するIPアドレスを持つエンティティを指し、「L」、「R」、「STUN」、または「NAT」のいずれかです。タイプは、パブリックのトランスポートアドレスの場合は「PUB」、プライベートのトランスポートアドレスの場合は「PRIV」です。最後に、seq-noは、特定のエンティティの同じタイプのトランスポートアドレスごとに異なるシーケンス番号です。各変数には、それぞれvarname.IPとvarname.PORTで示されるIPアドレスとポートがあります。ここで、varnameは変数の名前です。 | |
| STUNサーバーは、トランスポートアドレスSTUN-PUB-1（192.0.2.2:3478）をアドバタイズしました。 | |
| コールフロー自体では、STUNメッセージにはいくつかの属性が付けられています。「S =」属性は、メッセージの送信元トランスポートアドレスを示します。「D =」属性は、メッセージの宛先トランスポートアドレスを示します。「MA =」属性は、STUNバインディング応答メッセージで使用され、マッピングされたアドレスを参照します。「USE-CAND」は、USE-CANDIDATE属性の存在を意味します。 | |
| コールフローの例では、STUN認証操作とRTCPを省略し、2つの完全な実装間の単一メディアストリームのRTPに焦点を当てています。 | |
| L NAT STUN R | RTP STUNアロケート。| | |（1）STUN Req | | | | S = $ L-PRIV-1 | | | | D = $ STUN-PUB-1 | | | | -------------> | | | | |（2）STUNリクエスト| | | | S = $ NAT-PUB-1 | | | | D = $ STUN-PUB-1 | | | | -------------> | | | |
| | |（3）STUN Res | | | | S = $ STUN-PUB-1 | | | | D = $ NAT-PUB-1 | | | | MA = $ NAT-PUB-1 | | | | <------------- | | |（4）STUN Res | | | | S = $ STUN-PUB-1 | | | | D = $ L-PRIV-1 | | | | MA = $ NAT-PUB-1 | | | | <------------- | | | |（5）オファー| | | | -------------------------------------------> | | | | | RTP STUNアロケート。| | |（6）STUN Req | | | | S = $ R-PUB-1 | | | | D = $ STUN-PUB-1 | | | | < ------------- | | | |（7）STUN Res | | | | S = $ STUN-PUB-1 | | | | D = $ R-PUB-1 | | | | MA = $ R-PUB-1 | | | | -------------> | |（8）回答| | | | <------------------------------------------- | | |（9）バインド要求| |開始| | S = $ R-PUB-1 | |接続性| | D = L-PRIV-1 | |チェック| | <---------------------------- | | |ドロップ| | |（10）バインド要求| | | | S = $ L-PRIV-1 | | | | D = $ R-PUB-1 | | | | USE-CAND | | | | -------------> | | | | |（11）バインド要求| | | | S = $ NAT-PUB-1 | | | | D = $ R-PUB-1 | | | | USE-CAND | | | | ----------------------------> | | |（12）バインド解像度| | | | S = $ R-PUB-1 | | | | D = $ NAT-PUB-1 | | | | MA = $ NAT-PUB-1 | | | | <---------------------------- | | | |（12）バインド解像度| | | | S = $ R-PUB-1 | | | | D = $ NAT-PUB-1 | | | | MA = $ NAT-PUB-1 | | | | <---------------------------- | | | |（12）バインド解像度| | | | S = $ R-PUB-1 | | | | D = $ NAT-PUB-1 | | | | MA = $ NAT-PUB-1 | | | | <---------------------------- | | |
| |（13）バインド解像度| | | | S = $ R-PUB-1 | | | | D = $ L-PRIV-1 | | | | MA = $ NAT-PUB-1 | | | | <------------- | | | | RTPフロー| | | | |（14）バインド要求| | | | S = $ R-PUB-1 | | | | D = $ NAT-PUB-1 | | | | <---------------------------- | |（15）バインド要求| | | | S = $ R-PUB-1 | | | | D = $ L-PRIV-1 | | | | < ------------- | | | |（16）バインド解像度| | | | S = $ L-PRIV-1 | | | | D = $ R-PUB-1 | | | | MA = $ R-PUB-1 | | | | -------------> | | | | |（17）バインド解像度| | | | S = $ NAT-PUB-1 | | | | D = $ R-PUB-1 | | | | MA = $ R-PUB-1 | | | | ----------------------------> | | | | | RTPフロー | | | | | RTPフロー | | | | | RTPフロー | |
| 図9：フローの例 | |
| 最初に、エージェントLはローカルIPアドレス（図示せず）からホスト候補を取得し、そこからSTUNバインディング要求をSTUNサーバーに送信してサーバー反射候補を取得します（メッセージ1〜4）。NATにはアドレスとポートに依存しないマッピングプロパティがあることを思い出してください。ここでは、このUDP要求に対してNAT-PUB-1のバインディングを作成し、これがRTPのサーバー反射候補になります。 | |
| エージェントLは、ホスト候補に126、サーバー反射に100のタイププリファレンスを設定します。ローカルプリファレンスは65535です。これに基づいて、ホスト候補の優先順位は2130706431であり、サーバー反射候補の場合は1694498815です。ホスト候補には1の基礎が割り当てられ、サーバー反射には2の基礎が割り当てられます。サーバーの再帰候補をデフォルト候補として使用し、mおよびc行にエンコードします。結果のオファー（メッセージ5）は次のようになります（わかりやすくするために行を折り返しています）。 | |
| v = 0 o = jdoe 2890844526 2890842807 IN IP4 $ L-PRIV-1.IP s = c = IN IP4 $ NAT-PUB-1.IP t = 0 0 a = ice-pwd：asd88fgpdd777uzjYhagZg a = ice-ufrag：8hhY m = audio $ NAT-PUB-1.PORT RTP / AVP 0 b = RS：0 b = RR：0 a = rtpmap：0 PCMU / 8000 a = candidate：1 1 UDP 2130706431 $ L-PRIV-1.IP $ L-PRIV-1.PORT typ host a = candidate：2 1 UDP 1694498815 $ NAT-PUB-1.IP $ NAT-PUB-1.PORT typ srflx raddr $ L-PRIV-1.IP rport $ L-PRIV- 1.ポート | |
| 変数が値に置き換えられたオファーは、次のようになります（わかりやすくするために行を折り返しています）。 | |
| v = 0 o = jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s = c = IN IP4 192.0.2.3 t = 0 0 a = ice-pwd：asd88fgpdd777uzjYhagZg a = ice-ufrag：8hhY m = audio 45664 RTP / AVP 0 b = RS：0 b = RR：0 a = rtpmap：0 PCMU / 8000 a = candidate：1 1 UDP 2130706431 10.0.1.1 8998 typ host a = candidate：2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 | |
| このオファーはエージェントRで受信されます。エージェントRはホスト候補を取得し、そこからサーバー反射候補を取得します（メッセージ6〜7）。RはNATの背後にないため、この候補はホスト候補と同一であり、同じベースを共有します。したがって、この冗長な候補は破棄され、単一のホスト候補になります。Lと同じタイプおよびローカルプリファレンスを使用すると、この候補の優先順位は2130706431です。単一の候補に対して1の基礎を選択します。結果の答えは次のようになります。 | |
| v = 0 o = bob 2808844564 2808844564 IN IP4 $ R-PUB-1.IP s = c = IN IP4 $ R-PUB-1.IP t = 0 0 a = ice-pwd：YH75Fviy6338Vbrhrlp8Yh a = ice-ufrag：9uB6 m = audio $ R-PUB-1.PORT RTP / AVP 0 b = RS：0 b = RR：0 a = rtpmap：0 PCMU / 8000 a = candidate：1 1 UDP 2130706431 $ R-PUB-1.IP $ R-PUB-1.PORT typホスト | |
| 変数が入力されている場合： | |
| v = 0 o = bob 2808844564 2808844564 IN IP4 192.0.2.1 s = c = IN IP4 192.0.2.1 t = 0 0 a = ice-pwd：YH75Fviy6338Vbrhrlp8Yh a = ice-ufrag：9uB6 m = audio 3478 RTP / AVP 0 b = RS：0 b = RR：0 a = rtpmap：0 PCMU / 8000 a = candidate：1 1 UDP 2130706431 192.0.2.1 3478 typ host | |
| どちらの側もライトであることを示していないため、ICE処理を開始したオファーを送信したエージェント（エージェントL）が制御エージェントになります。 | |
| エージェントLとRは両方とも候補をペアにします。最初は両方とも2つのペアがあります。ただし、エージェントLは、そのサーバーの再帰候補を含むペアを整理し、1つだけにします。エージェントLで、このペアには$ L_PRIV_1のローカル候補と$ R_PUB_1のリモート候補があり、候補ペアの優先度は4.57566E + 18です（失われないように実装はこれを64ビット整数として表すことに注意してください）精度）。エージェントRには、2つのペアがあります。最高の優先度には、ローカル候補$ R_PUB_1とリモート候補$ L_PRIV_1があり、優先度は4.57566E + 18であり、2番目はローカル候補$ R_PUB_1とリモート候補$ NAT_PUB_1と優先度3.63891E + 18です。 | |
| エージェントRは、最初のペア（2つのホスト候補の間）の接続性チェック（メッセージ9）を開始します。Rはこのセッションの制御エージェントであるため、チェックではUSE-CANDIDATE属性が省略されます。の | |
| エージェントLのホスト候補はプライベートであり、NATの背後にあるため、パケットをRからLにルーティングできないため、このチェックは成功しません。 | |
| エージェントLが回答を取得すると、唯一の接続チェックを実行します（メッセージ10〜13）。アグレッシブなノミネートアルゴリズムを実装するため、このチェックにUSE-CANDIDATE属性が含まれます。チェックが成功したため、エージェントLは新しいペアを作成し、そのローカル候補はバインディング応答のマッピングアドレスから（メッセージ13からのNAT-PUB-1）、リモート候補はリクエストの宛先（R-PUB-1）メッセージ10）から。これは有効なリストに追加されます。さらに、バインディングリクエストにUSE-CANDIDATE属性が含まれていたため、選択済みとしてマークされます。このメディアストリームの1つのコンポーネントの有効なリストに選択された候補があるため、このストリームのICE処理は完了状態に移行します。エージェントLは、必要に応じてメディアを送信できるようになりました。 | |
| エージェントLからのSTUN Binding要求の受信後すぐに（メッセージ11）、エージェントRはトリガーされたチェックを生成します。このチェックは、ホスト候補からエージェントLのサーバー再帰候補まで、チェックリストの次のチェックと一致します。このチェック（メッセージ14〜17）は成功します。その結果、エージェントRは、ローカル候補としての応答（R-PUB-1）からのマッピングアドレスと、リモート候補としての要求の宛先（NAT-PUB-1）を使用して、新しい候補ペアを構築します。このペアは、そのメディアストリームの有効なリストに追加されます。チェックはUSE-CANDIDATE属性を含むチェックの逆方向に生成されたため、候補ペアは選択済みとしてマークされます。その結果、このストリームの処理は完了状態に移行し、エージェントRもメディアを送信できます。 | |
| 18.セキュリティに関する考慮事項 | |
| ICEシステムでは、いくつかの種類の攻撃が可能です。このセクションでは、これらの攻撃とその対策について検討します。これらの対策には以下が含まれます。 | |
| o ICEをSIPSなどの安全な信号技術と組み合わせて使用します。 | |
| o接続チェックの合計数を100に制限し、オプションでオファーまたはアンサーで受け入れる候補者の数を制限します。 | |
| 18.1。接続性チェックへの攻撃 | |
| 攻撃者は、STUN接続チェックを妨害しようとする可能性があります。最終的に、これらの攻撃はすべて、エージェントをだまして、接続性チェックの結果について何か間違ったことを考えさせます。攻撃者が試みる可能性のある誤った結論は次のとおりです。 | |
| False無効：攻撃者は、エージェントのペアをだまして、候補のペアが無効であると見なすことができます。これを使用して、エージェントに別の候補（攻撃者によって注入された候補など）を優先させたり、すべての候補を強制的に失敗させてコールを中断したりできます。 | |
| False Valid：攻撃者は、1組のエージェントがだまされて、候補の組が有効でないと考えます。これにより、エージェントはセッションを続行できますが、メディアを受信できなくなります。 | |
| False Peer Reflexive Candidate：攻撃者は、あるべきではないときに、エージェントに新しいピア反射候補を発見させることができます。これは、盗聴またはその他の目的で、メディアストリームをサービス拒否（DoS）ターゲットまたは攻撃者にリダイレクトするために使用できます。 | |
| 偽候補の偽有効：攻撃者は、実際にそのエージェントにルーティングされないアドレスを持つ候補が存在することをエージェントにすでに確信させています（たとえば、偽のピア反射候補または偽サーバー反射候補を注入することによって）。次に、この候補が有効であるとエージェントに信じ込ませる攻撃を開始する必要があります。 | |
| 攻撃者が、偽のピア反射候補または偽の候補に対する偽の有効を引き起こすことができる場合、[RFC5389]で説明されている攻撃のいずれかを起動できます。 | |
| 誤った無効な結果を強制するには、攻撃者はエージェントの1つからの接続チェックが送信されるのを待つ必要があります。存在する場合、攻撃者は400などの回復不能なエラー応答を含む偽の応答を挿入する必要があります。ただし、候補は実際には有効であるため、元の要求はピアエージェントに到達し、成功の応答を返す可能性があります。攻撃者は、DoS攻撃、レイヤー2ネットワークの中断、またはその他の手法により、このパケットまたはその応答を強制的にドロップする必要があります。これを行わない場合、成功応答も発信者に届き、攻撃の可能性を警告します。幸いなことに、この攻撃は、STUN短期資格情報メカニズムによって完全に軽減されます。攻撃者は偽の応答を挿入する必要があり、この応答を処理するために、攻撃者はパスワードが必要です。 | |
| 偽の有効な結果を強制することも同様の方法で機能します。エージェントは、各エージェントからのバインディング要求を待機し、偽の成功応答を注入する必要があります。候補者が有効でない場合は、とにかく受信されないため、攻撃者は実際の応答を中断することを心配する必要はありません。ただし、偽の無効な攻撃と同様に、この攻撃は、安全なオファー/アンサー交換と連携したSTUN短期資格情報メカニズムによって軽減されます。 | |
| 偽のピア再帰候補の結果を強制することは、偽の要求または応答、またはリプレイで実行できます。まず、偽のリクエストとレスポンスのケースを検討します。攻撃者は、偽の候補のソースIPアドレスとポートを使用して、1つのエージェントにバインド要求を送信する必要があります。さらに、攻撃者は他のエージェントからのバインディングリクエストを待機し、偽の候補を含むXOR-MAPPED-ADDRESS属性を持つ偽の応答を生成する必要があります。ここで説明する他の攻撃と同様に、この攻撃はSTUNメッセージ整合性メカニズムと安全なオファー/アンサー交換によって緩和されます。 | |
| パケットリプレイでの偽のピア再帰候補の結果の強制は異なります。攻撃者は、エージェントの1人がチェックを送信するまで待機します。この要求をインターセプトし、偽のソースIPアドレスを持つ他のエージェントに向けてリプレイします。また、DoS攻撃を開始してパケットをドロップするか、レイヤー2メカニズムを使用して強制的にドロップすることにより、元の要求がリモートエージェントに到達しないようにする必要があります。再生されたパケットは、整合性チェックに合格するため、他のエージェントで受信され、受け入れられます（整合性チェックはソースIPアドレスとポートをカバーできないため、カバーしません）。その後、応答されます。この応答には、偽の候補を持つXOR-MAPPED-ADDRESSが含まれ、その偽の候補に送信されます。攻撃者はそれを受信し、発信者に中継する必要があります。 | |
| 次に、他のエージェントは、その偽の候補に対する接続チェックを開始します。この検証は成功する必要があります。これは、攻撃者が偽の候補に対して偽の有効を強制することを必要とします。この目標を達成するための偽の要求または応答の注入は、STUNの整合性メカニズムとオファー/アンサー交換を使用して防止されます。したがって、この攻撃はリプレイによってのみ開始できます。そのためには、攻撃者はこの偽の候補に対するチェックを傍受し、他のエージェントに対してリプレイする必要があります。次に、応答をインターセプトし、同様に再生する必要があります。 | |
| この攻撃は、攻撃者が偽の候補者によって識別されない限り、開始するのが非常に困難です。これは、攻撃者が2つの異なるホストから送信されたパケットを傍受して再生する必要があるためです。両方のエージェントが異なるネットワーク上にある場合（たとえば、パブリックインターネット全体）、この攻撃はネットワークの異なる部分にある2つの異なるエンドポイントに対して同時に発生する必要があるため、調整が難しい場合があります。 | |
| 攻撃者自身が偽の候補者によって識別された場合、攻撃の調整が容易になります。ただし、SRTPが使用されている場合[RFC3711]、攻撃者はメディアパケットを再生できず、それらを破棄することしかできず、通話のメディアストリームを事実上無効にします。ただし、この攻撃では、接続チェックがターゲットに到達するのをブロックするために、エージェントがパケットを中断する必要があります。その場合、目標がメディアストリームを中断することである場合、ICEを攻撃するのではなく、同じメカニズムで単に中断する方がはるかに簡単です。 | |
| 18.2。サーバーの再帰アドレス収集に対する攻撃 | |
| ICEエンドポイントは、STUNバインディング要求を使用して、STUNサーバーからサーバーの再帰候補を収集します。これらのリクエストは認証されません。結果として、攻撃者がクライアントに偽のサーバー再帰候補を提供するために使用できる多くの手法があります。 | |
| o攻撃者はDNSを侵害し、DNSクエリが不正なSTUNサーバーアドレスを返す可能性があります。そのサーバーは、クライアントに偽サーバーの再帰候補を提供できます。この攻撃はDNSセキュリティによって軽減されますが、DNS-SECはそれに対処する必要はありません。 | |
| o STUNメッセージを観測できる攻撃者（WiFiなどの共有ネットワークセグメントの攻撃者など）は、有効でクライアントに受け入れられる偽の応答を挿入できます。 | |
| o攻撃者はウイルスによってSTUNサーバーを侵害し、不正なマッピングアドレスで応答を送信させることができます。 | |
| これらの攻撃によって学習された誤ってマッピングされたアドレスは、ICE交換のサーバー反射候補として使用されます。この候補が実際にメディアに使用されるためには、攻撃者は接続チェックも攻撃する必要があり、特に、偽の候補に対して偽の有効を強制する必要があります。この攻撃は、セッション内の各エージェントによって生成されたチェックを攻撃する必要があるため、偽のアドレスが第4者（提供者、回答者、攻撃者のいずれでもない）を識別する場合、開始するのが非常に難しく、攻撃者を識別する場合SRTPによって防止されます彼ら自身。 | |
| 攻撃者が接続性チェックを攻撃しないことを選択した場合、最悪の事態は、サーバーの再帰候補が使用されないようにすることです。ただし、攻撃を受けているエージェントが到達可能な候補がピアエージェントに少なくとも1つある場合、STUN接続性チェック自体が、メディアの交換に使用できるピア反射候補を提供します。通常、ピア反射候補はサーバー反射候補よりも優先されます。そのため、STUNアドレス収集のみに対する攻撃は通常、セッションにまったく影響を与えません。 | |
| 18.3。リレーされた候補者の収集に対する攻撃 | |
| 攻撃者は、リレーされた候補者の収集を妨害し、クライアントに誤ったリレーされた候補者があると信じ込ませようとする可能性があります。TURNサーバーとの交換は、長期資格情報を使用して認証されます。したがって、偽の応答または要求の注入は機能しません。さらに、バインディング要求とは異なり、割り当て要求は、ソースIPアドレスとポートがクライアントにリレー候補を提供するために使用されないため、変更されたソースIPアドレスとポートを使用したリプレイ攻撃の影響を受けません。 | |
| ただし、TURNサーバーは、ゾンビサーバーまたは不正サーバーに変換する目的で、DNS攻撃またはTURNサーバーを対象としたウイルスの影響を受けやすくなっています。これらの攻撃は、DNS-SECによって、またTURNサーバー上の適切なボックスおよびソフトウェアセキュリティを通じて軽減できます。 | |
| 攻撃者がクライアントに誤った中継候補を信じさせたとしても、接続性チェックにより、そのような候補は成功した場合にのみ使用されます。したがって、攻撃者は上記のように偽の候補に対して偽の有効を起動する必要があり、これは調整が非常に難しい攻撃です。 | |
| 18.4。オファー/アンサー交換に対する攻撃 | |
| オファー/アンサー交換自体を変更または妨害できる攻撃者は、ICEを使用してさまざまな攻撃を容易に開始できます。メディアをDoS攻撃の標的に誘導したり、メディアストリームに自分自身を挿入したりできます。これらは、オファー/アンサー交換の一般的なセキュリティの考慮事項に似ており、RFC 3264 [RFC3264]のセキュリティの考慮事項が適用されます。これらには、メッセージの整合性と、オファーとアンサーの暗号化のための技術が必要です。これは、SIPが使用される場合、SIPSメカニズム[RFC3261]によって満たされます。そのため、ICEでのSIPSの使用が推奨されます。 | |
| 18.5。インサイダー攻撃 | |
| 攻撃者が偽のオファー、回答、またはスタンメッセージを挿入しようとする第三者である攻撃に加えて、攻撃者がICE交換の認証された有効な参加者である場合、ICEで可能な攻撃がいくつかあります。 | |
| 18.5.1。音声ハンマー攻撃 | |
| 音声ハンマー攻撃は増幅攻撃です。この攻撃では、攻撃者は他のエージェントへのセッションを開始し、SDPでシグナリングされるメディアトラフィックの宛先としてDoSターゲットのIPアドレスとポートを悪意を持って含めます。これはかなりの増幅を引き起こします。単一のオファー/アンサー交換は、おそらく高レートでメディアパケットのフラッディングを継続的に発生させる可能性があります（ビデオソースを考慮）。この攻撃はICEに固有のものではありませんが、ICEは修復の提供に役立ちます。 | |
| 具体的には、ICEが使用される場合、悪意のあるSDPを受信するエージェントは、メディアを送信する前にメディアのターゲットへの接続性チェックを最初に実行します。このターゲットがサードパーティのホストである場合、チェックは成功せず、メディアは送信されません。 | |
| 残念ながら、ICEは使用されない場合は役に立ちません。その場合、攻撃者はICEパラメータなしでオファーを送信するだけです。ただし、クライアントのセットが既知であり、ICEをサポートするものに限定されている環境では、サーバーはICEサポートを示さないオファーまたは回答を拒否できます。 | |
| 18.5.2。スタン増幅攻撃 | |
| STUN増幅攻撃は、音声ハンマーに似ています。ただし、音声パケットがターゲットに送信される代わりに、STUN接続チェックはターゲットに送信されます。攻撃者は多数の候補、たとえば50のオファーを送信します。回答者はオファーを受信し、ターゲットに向けられたチェックを開始します。その結果、応答を生成しません。回答者は、Ta ms（たとえば、Ta = 20ms）ごとに新しい接続チェックを開始します。ただし、再送信タイマーは、多数の候補のために多数に設定されます。結果として、パケットはTaミリ秒ごとに1つの間隔で送信され、その後は間隔が長くなります。したがって、STUNはメディアが送信されるよりも速い速度でパケットを送信せず、セッションでICEが失敗するまで、STUNパケットは短時間しか持続しません。 | |
| 増幅を排除することは不可能ですが、さまざまなヒューリスティックによってボリュームを減らすことができます。エージェントは、実行する接続チェックの合計数を100に制限する必要があります。さらに、エージェントは、オファーまたはアンサーで受け入れる候補者の数を制限することができます。 | |
| 多くの場合、これらの種類の攻撃を回避したいプロトコルは、次のメッセージを送信する前に、イニシエーターに応答を待たせます。ただし、ICEの場合、これは不可能です。次の2つのケースを区別することはできません。 | |
| oイニシエーターは、応答しない疑いのないターゲットに対してDoS攻撃を開始するために使用されているため、応答はありませんでした。 | |
| oイニシエーターがIPアドレスとポートに到達できないため、応答がありませんでした。 | |
| 2番目のケースでは、次の機会に別のチェックを送信する必要がありますが、前者のケースでは、さらにチェックを送信する必要はありません。 | |
| 18.6。アプリケーションレイヤーゲートウェイおよびSIPとの相互作用 | |
| アプリケーション層ゲートウェイ（ALG）は、アプリケーションプロトコルのNATトラバーサルを容易にするために、パケットの内容を検査して変更するNATデバイスに存在する機能です。セッションボーダーコントローラー（SBC）はALGと密接な関係にありますが、アプリケーションレイヤーSIP仲介者として実際に存在するため、透過性は低くなります。ICEは、SBCおよびALGと相互作用します。 | |
| ALGがSIPを認識しているがICEを認識していない場合、ALGがSDPを正しく変更する限り、ICEはそれを処理します。正しいALG実装は次のように動作します。 | |
| o外部アドレスが含まれている場合、ALGはmおよびc行またはrtcp属性を変更しません。 | |
| o mおよびc行に内部アドレスが含まれる場合、変更はALGの状態に依存します。 | |
| ALGに外部ポートを内部IPアドレスにマッピングするバインディングが既に確立されていて、mおよびc行またはrtcp属性の値に一致するポートがある場合、ALGは新しいバインディングを作成する代わりにそのバインディングを使用します。 | |
| ALGにバインディングがまだない場合は、新しいバインディングを作成してSDPを変更し、mおよびc行とrtcp属性を書き換えます。 | |
| 残念ながら、多くのALGはこれらのケースではうまく機能しないことが知られています。ICEは、機能の範囲外であるため、破損したALGを回避しようとしません。ICEは、これらの状態の診断に役立ちます。これらの状態は、候補のセットとmおよびcの行とrtcp属性との不一致として表示されることがよくあります。この目的には、氷の不一致属性が使用されます。 | |
| ICEが、シグナリングがTLSを介して実行される場合、ALGを介して最適に機能します。これにより、ALGがSDPメッセージを操作してICE操作を妨害することを防ぎます。ALGの背後に展開されることが期待される実装は、SDPのTLSトランスポートを提供する必要があります。 | |
| SBCがSIPを認識し、ICEを認識しない場合、結果はSBCの動作に依存します。適切なBack-to-Back User Agent（B2BUA）として機能している場合、SBCは、ICE属性など、理解できないSDP属性を削除します。その結果、相手側がICEをサポートしていないかのように、両方のエンドポイントにコールが表示されます。これにより、SBCが要求した場合、ICEが無効になり、メディアがSBCを通過します。ただし、SBCが変更せずにICE属性を渡し、さらにメディアのデフォルトの宛先（mおよびc行とrtcp属性に含まれる）を変更すると、これはICE不一致として検出され、コールのICE処理は中止されます。 。SBCを「回避する」ためのツールとして機能することは、ICEの範囲外です。存在する場合、 | |
| 19. STUNエクステンション | |
| 19.1。新しい属性 | |
| この仕様では、4つの新しい属性、PRIORITY、USE-CANDIDATE、ICE-CONTROLLED、およびICE-CONTROLLINGを定義しています。 | |
| PRIORITY属性は、このチェックで発見された場合に、ピアの再帰候補に関連付けられる優先順位を示します。32ビットの符号なし整数であり、属性値は0x0024です。 | |
| USE-CANDIDATE属性は、このチェックの結果の候補ペアをメディアの送信に使用する必要があることを示します。属性にはコンテンツがありません（属性の長さフィールドはゼロです）。フラグとして機能します。属性値は0x0025です。 | |
| ICE-CONTROLLED属性はバインディング要求に存在し、クライアントが現在制御されている役割にあるとクライアントが信じていることを示します。属性の内容は、ネットワークバイトオーダーの64ビット符号なし整数であり、ロール競合のタイブレークに使用される乱数が含まれています。ICE-CONTROLLING属性はバインディングリクエストに存在し、クライアントが現在それが制御ロールにあると信じていることを示します。属性の内容は、ネットワークバイトオーダーの64ビット符号なし整数であり、ロール競合のタイブレークに使用される乱数が含まれています。 | |
| 19.2。新しいエラー応答コード | |
| この仕様では、単一のエラー応答コードを定義しています。 | |
| 487（ロールの競合）：バインド要求には、サーバーと競合するロールを示すICE-CONTROLLINGまたはICE-CONTROLLED属性のいずれかが含まれていました。サーバーは、要求内のタイブレーカー値に基づいてタイブレーカーを実行し、クライアントが役割を切り替える必要があると判断しました。 | |
| 20.操作上の考慮事項 | |
| このセクションでは、ICEの展開を検討しているネットワークオペレーターに関連する問題について説明します。 | |
| 20.1。NATおよびファイアウォールタイプ | |
| ICEは、既存のNATおよびファイアウォール機器で動作するように設計されました。したがって、ICEの展開を容易にするために、既存のファイアウォールおよびNAT機器を交換または再構成する必要はありません。実際、ICEは、Voice over IP（VoIP）オペレーターがファイアウォールやNATなどのIPネットワークインフラストラクチャを制御できない環境に展開されるように開発されました。 | |
| とは言っても、ICEは[RFC4787]および[RFC5766]で定義されている推奨事項を満たし、NATデバイスが「動作」に準拠している環境で最適に機能します。動作準拠のNATを備えたネットワークでは、ICEはTURNサーバーを必要とせずに動作するため、音声品質が向上し、コールセットアップ時間が短縮され、ネットワークオペレーターの帯域幅需要が削減されます。 | |
| 20.2。帯域幅の要件 | |
| ICEの展開では、オペレーターが考慮する必要がある利用可能なネットワーク容量といくつかの相互作用があります。 | |
| 20.2.1。STUNおよびTURN Serverの容量計画 | |
| 何よりもまず、ICEはTURNおよびSTUNサーバーを利用します。これらは通常、ネットワークオペレーターのデータセンターに配置されます。STUNサーバーは、比較的小さな帯域幅しか必要としません。各メディアストリームの各コンポーネントには、各クライアントからSTUNサーバーへの1つ以上のSTUNトランザクションがあります。基本的な音声のみのIPv4 VoIP展開では、呼び出しごとに4つのトランザクションがあります（RTPに1つ、RTCPに1つ、呼び出し元と呼び出し先の両方に）。各トランザクションは単一の要求と単一の応答であり、前者の長さは20バイト、後者の長さは28です。したがって、システムにN人のユーザーがいて、それぞれが忙しい時間に4つの呼び出しを行う場合、N * 1.7bpsが必要になります。100万人のユーザーの場合、これは1.7 Mbpsであり、非常に少ない数です（比較的）。 | |
| TURNトラフィックはより重要です。TURNサーバーは、実際のメディアトラフィックのトラフィックに加えて、STUNボリュームに等しいトラフィックボリューム（実際、TURNサーバーが展開されている場合、別個のSTUNサーバーは必要ありません）を確認します。メディアリレーにTURNを必要とするコールの量は、ネットワークトポロジに大きく依存し、時間とともに変化する可能性があります。100％動作準拠のNATを使用するネットワークでは、正確にゼロです。この記事の執筆時点では、大規模なコンシューマー展開では、TURNサーバーを必要とする呼び出しの5〜10％が発生していました。G.711（各方向で80 kbps）を使用して、繁忙時間中に.2アーランで音声のみの展開を検討すると、これはN * 3.2 kbpsです。人口100万人の場合、これは3.2 Gbpsであり、TURNサーバーの10％の使用を想定しています。 | |
| 20.2.2。収集および接続性チェック | |
| 候補者を収集し、接続性チェックを実行するプロセスは、帯域幅を集中的に使用する場合があります。ICEは、これらのプロセスの両方に対応するように設計されています。収集フェーズと接続チェックフェーズは、メディアトラフィック自体とほぼ同じ帯域幅でトラフィックを生成することを目的としています。これは、ネットワークが特定のタイプ（音声、ビデオ、またはテキストのみ）のマルチメディアトラフィックをサポートするように設計されている場合、そのメディアのICEチェックをサポートするのに十分な容量を確保するために行われました。もちろん、ICEチェックにより、総使用率がわずかに増加します。ただし、これは通常非常に小さな増加になります。 | |
| 収集およびチェックフェーズによる輻輳は、ペーシングを使用しなかった展開の問題であることが証明されています。通常、アクセスリンクは、エンドポイントが送信可能な限り高速のチェックでネットワークをあふれさせるため、輻輳しました。したがって、ネットワークオペレータは、ICE実装がペーシング機能をサポートしていることを確認する必要があります。このペーシングによりコールのセットアップ時間が長くなりますが、ICEネットワークが使いやすくなり、展開が容易になります。 | |
| 20.2.3。キープアライブ | |
| STUNキープアライブ（STUNバインディングインジケーションの形式）は、メディアセッションの途中で送信されます。ただし、実際のメディアトラフィックがない場合にのみ送信されます。Voice Activity Detection（VAD）を利用していない展開では、キープアライブは使用されず、帯域幅の使用量は増加しません。VADが使用されている場合、無音期間中にキープアライブが送信されます。これには、音声があるときに送信される20〜30ミリ秒ごとのパケットよりもはるかに少ない、15〜20秒ごとの単一パケットが含まれます。したがって、キープアライブはキャパシティプランニングに実際の影響を与えません。 | |
| 20.3。ICEおよびICE-lite | |
| ICEとICE-liteを組み合わせて利用する展開は完全に相互運用できます。機能を失うことなく、そうするように明示的に設計されています。 | |
| ただし、ICE-liteは限られたユースケースでのみ展開できます。これらのケース、およびそれに関する注意事項は、付録Aに記載されています。 | |
| 20.4。トラブルシューティングとパフォーマンス管理 | |
| ICEはエンドツーエンドの接続性チェックを利用し、処理の大部分をエンドポイントに配置します。これは、ネットワークオペレーターに課題をもたらします-ICE展開のトラブルシューティング方法は？ICEのパフォーマンスをどのように知ることができますか？ | |
| ICEには、これらの問題に対処するための組み込み機能があります。通常、ネットワークオペレーターのデータセンターに展開されているシグナリングパス上のSIPサーバーは、ICEパラメーターを伝達するオファー/アンサー交換の内容を確認します。これらのパラメーターには、各候補のタイプ（ホスト、反射サーバー、またはリレー）が、関連アドレスとともに含まれます。ICE処理が完了すると、更新されたオファー/アンサー交換が行われ、選択したアドレス（およびそのタイプ）が通知されます。この更新されたre-INVITEは、ICE処理の結果についてネットワーク機器（SIPサーバーに接続された診断ツールなど）を教育する目的で正確に実行されます。 | |
| 結果として、SIPサーバーによって生成されたログを介して、ネットワークオペレーターは、各呼び出しで使用されている候補の種類と、ICEによって選択されたアドレスを確認できます。これは、ICEのパフォーマンスの評価に役立つ主要な情報です。 | |
| 20.5。エンドポイント構成 | |
| ICEは、エンドポイントに構成されているいくつかのデータに依存しています。この構成データには、タイマー、TURNサーバーの資格情報、STUNおよびTURNサーバーのホスト名が含まれます。ICE自体は、この構成のメカニズムを提供しません。代わりに、この情報は、エンドポイントの他のすべてのパラメーターを構成するために使用されるメカニズムに添付されると想定されています。SIP電話機の場合、構成フレームワーク[SIP-UA-FRMWK]などの標準ソリューションが定義されています。 | |
| 21. IANAの考慮事項 | |
| この仕様は、新しいSDP属性、4つの新しいSTUN属性、および1つの新しいSTUNエラー応答を登録します。 | |
| 21.1。SDP属性 | |
| この仕様は、[RFC4566]のセクション8.2.4の手順ごとに7つの新しいSDP属性を定義します。登録に必要な情報はここに含まれています。 | |
| 21.1.1。候補属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：候補 | |
| 長い形式：候補者 | |
| 属性のタイプ：メディアレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性は、Interactive Connectivity Establishment（ICE）で使用され、通信に使用できる多数の候補アドレスの1つを提供します。これらのアドレスは、NAT（STUN）のセッショントラバーサルユーティリティを使用したエンドツーエンドの接続性チェックで検証されます。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.2。リモート候補属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：リモート候補 | |
| 長い形式：リモート候補 | |
| 属性のタイプ：メディアレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。目的：この属性は、Interactive Connectivity Establishment（ICE）で使用され、オファー側が回答者が回答で使用することを望むリモート候補者のIDを提供します。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.3。アイスライト属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：ice-lite | |
| ロングフォーム：アイスライト | |
| 属性のタイプ：セッションレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性は、Interactive Connectivity Establishment（ICE）で使用され、完全な実装を持つピアとのICE相互運用をサポートするために必要な最小限の機能がエージェントにあることを示します。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.4。アイスミスマッチ属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：アイスミスマッチ | |
| 長い形式：氷の不一致 | |
| 属性のタイプ：セッションレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性は、Interactive Connectivity Establishment（ICE）で使用され、エージェントがICE対応であることを示しますが、SDPで通知されるメディアのデフォルトの宛先と候補が一致しないため、ICEを続行しませんでした。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.5。ice-pwd属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：ice-pwd | |
| 長い形式：ice-pwd | |
| 属性のタイプ：セッションレベルまたはメディアレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性はInteractive Connectivity Establishment（ICE）で使用され、STUN接続チェックを保護するために使用されるパスワードを提供します。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.6。ice-ufrag属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：ice-ufrag | |
| 長い形式：ice-ufrag | |
| 属性のタイプ：セッションレベルまたはメディアレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性はInteractive Connectivity Establishment（ICE）で使用され、STUN接続チェックでユーザー名を構成するために使用されるフラグメントを提供します。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.1.7。ice-options属性 | |
| 連絡先：ジョナサンローゼンバーグ、jdrosen @ jdrosen.net。 | |
| 属性名：ice-options | |
| 長い形式：氷のオプション | |
| 属性のタイプ：セッションレベル | |
| 文字セットに関する考慮事項：属性は文字セット属性の影響を受けません。 | |
| 目的：この属性はInteractive Connectivity Establishment（ICE）で使用され、エージェントが使用するICEオプションまたは拡張機能を示します。 | |
| 適切な値：RFC 5245のセクション15を参照してください。 | |
| 21.2。STUN属性 | |
| このセクションは、[RFC5389]の手順ごとに4つの新しいSTUN属性を登録します。 | |
| 0x0024優先度0x0025使用候補0x8029氷制御0x802A氷制御 | |
| 21.3。STUNエラー応答 | |
| このセクションは、[RFC5389]の手順ごとに1つの新しいSTUNエラー応答コードを登録します。 | |
| 487ロールの競合：クライアントは、サーバーのロールと競合するICEロール（制御または制御）をアサートしました。 | |
| 22. IABの考慮事項 | |
| IABは、エージェントが協調プロトコルリフレクションメカニズム[RFC3424]を介してNATの反対側にある別の領域でアドレスを決定しようとする一般的なプロセスである「片側自己アドレス修正」の問題を研究しました。ICEは、このタイプの機能を実行するプロトコルの例です。興味深いことに、ICEのプロセスは一方的ではなく、二国間であり、その違いはIABによって提起された問題に大きな影響を及ぼします。実際、ICEはUNSAFプロトコルではなく、B-SAF（Bilateral Self-Address Fixing）プロトコルと見なすことができます。とにかく、IABは、この目的のために開発されたプロトコルは、特定の考慮事項を文書化することを義務付けています。このセクションはそれらの要件を満たしています。 | |
| 22.1。問題定義 | |
| > RFC 3424から、UNSAFの提案は以下を提供する必要があります。 | |
| UNSAF提案で解決される特定の限定された範囲の問題の正確な定義。他の問題を解決するために短期的な修正を一般化すべきではありません。これが「通常、短期的な修正がそうではない」理由です。 | |
| ICEによって解決される特定の問題は次のとおりです。 | |
| 2つのピアが通信に使用できるトランスポートアドレスのセットを決定する手段を提供します。 | |
| エージェントが通信を希望する別のピアから到達可能なアドレスを決定する手段を提供します。 | |
| 22.2。出口戦略 | |
| > RFC 3424から、UNSAFの提案は以下を提供する必要があります。 | |
| 出口戦略/移行計画の説明。より適切な短期的な修正は、適切な技術が展開されるにつれて、当然ながら使用が少なくなる修正です。 | |
| ICE自体は簡単に段階的に廃止されません。ただし、たとえば、ルーターの障害によって接続が一時的に中断されたかどうかを検出する手段として、グローバルに接続されたインターネットでも役立ちます。ICEは、NATとは関係のない特定のセキュリティ攻撃の防止にも役立ちます。ただし、ICEが行うことは、他のUNSAFメカニズムを段階的に廃止することです。ICEはこれらのメカニズムの中から効果的に選択し、より良いメカニズムを優先し、より悪いメカニズムを優先しません。ローカルIPv6アドレスを優先することができます。IPv6が導入されるとNATが消失し始めるため、ネイティブホスト候補への優先度の高い接続が存在するため、サーバー反射型およびリレー候補（UNSAFアドレスの両方の形式）が使用されることはありません。したがって、サーバーはますます使用されなくなり、 | |
| 実際、ICEはIPv4からIPv6への移行を支援できます。2つのデュアルスタックホストがSIPと通信するときにIPv6とIPv4のどちらを使用するかを決定するために使用できます（IPv6が使用されます）。また、6to4接続とネイティブv6接続の両方を持つネットワークが、ピアと通信するときに使用するアドレスを決定できるようにすることもできます。 | |
| 22.3。ICEによって導入された脆性 | |
| > RFC 3424から、UNSAFの提案は以下を提供する必要があります。 | |
| システムをより「もろくする」特定の問題の議論。たとえば、複数のネットワーク層でデータを使用するアプローチでは、依存関係が増え、デバッグの課題が増え、移行が難しくなります。 | |
| ICEは、既存のUNSAFメカニズムから脆弱性を実際に取り除きます。特に、古典的なSTUN（RFC 3489 [RFC3489]で説明されている）には、いくつかの脆弱点があります。それらの1つは、エージェントが背後にあるNATのタイプを分類しようとすることを必要とするディスカバリプロセスです。このプロセスはエラーを起こしやすいです。ICEでは、その検出プロセスは単純に使用されません。アドレスの有効性を一方的に評価するのではなく、その有効性はピアへの接続性を測定することにより動的に決定されます。接続性を判断するプロセスは非常に堅牢です。 | |
| 古典的なSTUNおよびその他の片側メカニズムの脆弱性のもう1つのポイントは、追加サーバーへの絶対的な依存です。ICEは、サーバーを使用して一方的なアドレスを割り当てますが、可能であればエージェントが直接接続できるようにします。したがって、場合によっては、ICEの使用時にSTUNサーバーの障害により呼び出しが進行する可能性があります。 | |
| クラシックSTUNの脆弱性のもう1つのポイントは、STUNサーバーがパブリックインターネット上にあると想定していることです。興味深いことに、ICEでは、これは必要ありません。さまざまなアドレスレルムに多数のSTUNサーバーが存在する場合があります。ICEは、使用可能なアドレスを提供したものを検出します。 | |
| クラシックSTUNの脆弱性の最も厄介な点は、すべてのネットワークトポロジで機能しないことです。各エージェントとSTUNサーバーの間に共有NATがある場合、従来のSTUNが機能しない場合があります。ICEでは、その制限は削除されています。 | |
| Classic STUNでは、セキュリティに関する考慮事項もいくつか導入されています。幸いなことに、これらのセキュリティに関する考慮事項もICEによって緩和されます。 | |
| その結果、ICEは従来のSTUNで導入された脆弱性を修復する役割を果たし、システムに追加の脆弱性を導入しません。 | |
| これらの改善のペナルティは、ICEがセッション確立時間を増加させることです。 | |
| 22.4。長期的なソリューションの要件 | |
| RFC 3424から、UNSAFの提案は以下を提供する必要があります。 | |
| ...長期にわたる健全な技術的ソリューションの要件-適切な長期的ソリューションを見つけるプロセスに貢献します。 | |
| RFC 3489の結論は変わりません。ただし、ICEは長期的なソリューションの一部になり得ると考えているため、ICEが実際に役立つと感じています。 | |
| 22.5。既存のNAPTボックスに関する問題 | |
| RFC 3424から、UNSAFの提案は以下を提供する必要があります。 | |
| 既存の展開されたNA [P] Tと経験報告書に記載されている実際的な問題の影響についての議論。 | |
| 「汎用」ALG機能を提供しようとする多くのNATボックスが現在市場に展開されています。これらの汎用ALGは、パケット内のテキストまたはバイナリ形式のIPアドレスを探し、バインディングと一致する場合は書き換えます。これは、従来のSTUNに干渉します。ただし、STUN [RFC5389]の更新では、これらのバイナリアドレスを汎用ALGから隠すエンコードが使用されます。 | |
| 既存のNAPTボックスには、UDPベースのバインディングの非決定的で一般に短い有効期限があります。これには、実装がこれらのバインディングを維持するために定期的なキープアライブを送信する必要があります。ICEはデフォルトの15秒を使用しますが、これは非常に控えめな見積もりです。最終的に、NATボックスが動作するように準拠するようになると[RFC4787]、この最小キープアライブは決定論的で有名になり、ICEタイマーを調整できます。最小キープアライブインターバルを検出および制御する方法があると、さらに改善されます。 | |
| 23.謝辞 | |
| 著者は、コメントについてダン・ウィング、エリック・レスコーラ、フレミング・アンドレアセン、ディーン・ウィリス、エリック・クーパー、ジェイソン・フィッシュ、ダグラス・オーティス、ティム・ムーア、ジャン・フランソワ・ミュール、ケビン・ジョンズ、ジョナサン・レノックス、フランソワ・オーデに感謝しますそして入力。この仕様のいくつかの概念を提案したビル・メイ、この仕様の主要なパフォーマンス最適化の多くを提案したフィリップ・マシューズ、序文の文章を作成したエリック・レスコーラ、および実施するためのマグナス・ウェスターランドに特に感謝します。この仕様のさまざまな改訂に関するいくつかの詳細なレビュー。24.参照 | |
| 24.1。規範的参考文献 | |
| [RFC2119] Bradner、S.、「要求レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。 | |
| [RFC3605] Huitema、C。、「セッション記述プロトコル（SDP）のリアルタイム制御プロトコル（RTCP）属性」、RFC 3605、2003年10月。 | |
| [RFC3261]ローゼンバーグ、J。、シュルズリンネ、H。、カマリロ、G。、ジョンストン、A。、ピーターソン、J。、スパークス、R。、ハンドリー、M。、およびE.スクーラー、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。 | |
| [RFC3264]ローゼンバーグ、J。およびH.シュルズリンネ、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。 | |
| [RFC3556] Casner、S。、「RTP制御プロトコル（RTCP）帯域幅のためのセッション記述プロトコル（SDP）帯域幅修飾子」、RFC 3556、2003年7月。 | |
| [RFC3312]カマリロ、G。、マーシャル、W。、およびJ.ローゼンバーグ、「リソース管理とセッション開始プロトコル（SIP）の統合」、RFC 3312、2002年10月。 | |
| [RFC4032] Camarillo、G。、およびP. Kyzivat、「セッション開始プロトコル（SIP）前提条件フレームワークの更新」、RFC 4032、2005年3月。 | |
| [RFC3262] Rosenberg、J。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）の暫定応答の信頼性」、RFC 3262、2002年6月。 | |
| [RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。 | |
| [RFC4091] Camarillo、G.、J。Rosenberg、「セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。 | |
| [RFC4092] Camarillo、G。、およびJ. Rosenberg、「セッション記述プロトコル（SDP）代替ネットワークアドレスタイプ（ANAT）セマンティクスのセッション開始プロトコル（SIP）の使用」、RFC 4092、2005年6月。 | |
| [RFC3484] Draves、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。 | |
| [RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。 | |
| [RFC5389]ローゼンバーグ、J。、マヒー、R。、マシューズ、P。、およびD.ウィング、「NAT（STUN）のセッショントラバースユーティリティ」、RFC 5389、2008年10月。 | |
| [RFC5766] Mahy、R.、Matthews、P.、およびJ. Rosenberg、「NAT（TURN）でリレーを使用するトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張」、RFC 5766、2010年4月。 | |
| [RFC5768]ローゼンバーグ、J。、「セッション開始プロトコル（SIP）での対話型接続確立（ICE）のサポートの表示」、RFC 5768、2010年4月。 | |
| 24.2。参考資料 | |
| [RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「STUN-ネットワークアドレストランスレータ（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバース」、RFC 3489、2003年3月。 | |
| [RFC3235] Senie、D。、「Network Address Translator（NAT）-Friendly Application Design Guidelines」、RFC 3235、2002年1月。 | |
| [RFC3303] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「ミドルボックス通信アーキテクチャとフレームワーク」、RFC 3303、2002年8月。 | |
| [RFC3725]ローゼンバーグ、J。、ピーターソン、J。、シュルズリンネ、H。、およびG.カマリロ、「セッション開始プロトコル（SIP）のサードパーティコール制御（3pcc）の現在のベストプラクティス」、BCP 85、RFC 3725 、2004年4月。 | |
| [RFC3102] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm Specific IP：Framework」、RFC 3102、2001年10月。 | |
| [RFC3103] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Taniguchi、「Realm Specific IP：Protocol Specification」、RFC 3103、2001年10月。 | |
| [RFC3424] Daigle、L.およびIAB、「ネットワークアドレス変換を介した片側自己アドレス修正（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。 。、およびV.ジェイコブソン、「RTP：リアルタイムアプリケーションのトランスポートプロトコル」、STD 64、RFC 3550、2003年7月。 | |
| [RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、2004年3月。 | |
| [RFC3056]カーペンター、B.、K。ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。 | |
| [RFC3389] Zopf、R。、「コンフォートノイズ（CN）のリアルタイムトランスポートプロトコル（RTP）ペイロード」、RFC 3389、2002年9月。 | |
| [RFC3960] Camarillo、G。、およびH. Schulzrinne、「セッション開始プロトコル（SIP）での初期メディアおよび呼び出し音生成」、RFC 3960、2004年12月。 | |
| [RFC2475]ブレイク、S。、ブラック、D。、カールソン、M。、デイビーズ、E。、ワング、Z。、およびW.ヴァイス、「差別化されたサービスのためのアーキテクチャ」、RFC 2475、1998年12月。 | |
| [RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。 | |
| [RFC4787]オーデット、F。、およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。 | |
| [SDP-PRECON] Andreasen、F.、Camarillo、G.、Oran、D。、およびD. Wing、「セッション記述プロトコルメディアストリームの接続の前提条件」、Work in Progress、2010年3月。 | |
| [NO-OP-RTP] Andreasen、F.、Oran、D。、およびD. Wing、「RTPのNo-Opペイロードフォーマット」、Work in Progress、2007年5月。 | |
| [RFC5761] Perkins、C。、およびM. Westerlund、「単一ポートでのRTPデータと制御パケットの多重化」、RFC 5761、2010年4月。 | |
| [RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「データグラム輻輳制御プロトコル（DCCP）」、RFC 4340、2006年3月。 | |
| [RFC4103] Hellstrom、G。およびP. Jones、「テキスト会話のRTPペイロード」、RFC 4103、2005年6月。 | |
| [RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。 | |
| [RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、2008年10月。 | |
| [SIP-UA-FRMWK] Petrie、D.およびS. Channabasappa、Ed。、「セッション開始プロトコルユーザーエージェントプロファイル配信のフレームワーク」、Work in Progress、2010年2月。 | |
| [ICE-TCP]ペロー、S。、エド。およびJ. Rosenberg、「対話型接続確立（ICE）を使用するTCP候補者」、Work in Progress、2009年10月。 | |
| 付録A. Liteおよび完全な実装 | |
| ICEでは、2種類の実装が可能です。完全な実装では、セッション内の制御ロールと制御ロールがサポートされ、アドレス収集も実行できます。対照的に、ライト実装は最小限の実装であり、STUNチェックにほとんど応答しません。 | |
| ICEでは、どちらかのエンドポイントにメリットをもたらすために両方のエンドポイントがそれをサポートする必要があるため、ネットワークでのICEの増分展開はより複雑になります。多くのセッションには、NATの背後になく、NATトラバーサルを心配しないエンドポイント自体が含まれます。非常に一般的なケースは、NATトラバーサルを必要とする1つのエンドポイント（VoIPハード電話やソフト電話など）がこれらのデバイスの1つに電話をかけることです。電話機が完全なICE実装をサポートしていても、他のデバイスがICEをサポートしていない場合、ICEはまったく使用されません。ライトの実装により、これらのデバイスの低コストのエントリポイントが可能になります。lite実装をサポートすると、完全な実装がそれらに接続し、ICEのすべての利点を得ることができます。 | |
| したがって、Liteの実装は、*常に*パブリックインターネットに接続され、任意の通信相手からパケットを受信できるパブリックIPアドレスを持つデバイスにのみ適しています。ライトの実装がNATの背後に配置されている場合、ICEは機能しません。 | |
| ICEにより、Lite実装は単一のIPv4ホスト候補と複数のIPv6アドレスを持つことができます。その場合、候補ペアは、RFC 3484のような静的アルゴリズムを使用して、この仕様で推奨されている制御エージェントによって選択されます。ただし、アドレス選択の静的なメカニズムは、実際のトポロジを反映できず、接続に関する実際の保証を提供できないため、常にエラーが発生しやすくなります。それらは常にヒューリスティックです。したがって、エージェントがIPv4アドレスとIPv6アドレスを選択するためだけにICEを実装しており、IPアドレスがNATの背後にない場合、可能な限り最も堅牢な形式のアドレス選択を提供するために、完全なICEの使用が推奨されます。 | |
| 完全な実装への足掛かりを提供するために、この仕様にライト実装が追加されたことに注意することが重要です。常に単一のIPv4アドレスでパブリックインターネットに接続されているデバイスであっても、実現可能な場合は完全な実装が望ましいです。完全な実装では、ICEのアグレッシブモードを使用できるため、コールのセットアップ時間が短縮されます。完全な実装では、NATトラバーサルとは関係のないICEのセキュリティ上の利点も得られます。特に、セクション18で説明した音声ハンマー攻撃は、完全な実装に対してのみ防止され、完全な実装に対しては防止されません。最後に、今日パブリックアドレスを持つデバイスが明日ネットワークに配置され、NATの背後に配置されることがよくあります。デバイスまたは製品の耐用年数にわたって、明確に知ることは困難です。常に公共のインターネットで使用されること。完全な実装により、通信が常に機能することが保証されます。 | |
| 付録B.設計の動機 | |
| ICEには多数の規範的な動作が含まれており、それら自体は単純である場合がありますが、複雑なまたは非自明な思考や、さらなる議論に値するユースケースから派生しています。これらの設計の動機は、実装の目的で理解する必要はないため、ここでは仕様の付録で説明します。このセクションは非規範的です。 | |
| B.1。STUNトランザクションのペーシング | |
| 候補の収集と接続の検証に使用されるSTUNトランザクションは、Taミリ秒ごとに1つの新しいトランザクションの概算レートでペースアウトされます。同様に、各トランザクションには、Taの機能でもある再送信タイマーRTOがあります。なぜこれらのトランザクションはペース調整され、なぜこれらの式が使用されるのですか？ | |
| これらのSTUN要求の送信は、多くの場合、クライアントとSTUNサーバー間のNATデバイスにバインディングを作成する効果があります。多くのNATデバイスでは、新しいバインディングを作成するレートに上限があることが経験からわかっています。実験により、20ミリ秒ごとに1回が十分にサポートされていることが示されていますが、それより低くはありません。これが、Taの下限が20ミリ秒である理由です。さらに、ネットワーク上のこれらのパケットの送信は帯域幅を利用し、エージェントによってレート制限される必要があります。このドキュメントの以前のドラフトバージョンに基づいた展開は、ネットワークに悪影響を与えることに加えて、アクセスリンクの負荷が過負荷になり、全体的なパフォーマンスが低下する傾向がありました。結果として、ペーシングにより、NATデバイスが過負荷にならず、トラフィックが適切なレートに維持されることが保証されます。 | |
| 「合理的な」レートの定義は、メディアが流れ始めると、STUNはRTP自体が使用するよりも多くの帯域幅を使用しないことです。Taの式は、STUNパケットがTa秒ごとに送信されると、RTPパケットと同じ量の帯域幅を消費し、すべてのメディアストリームで合計されるように設計されています。もちろん、STUNには再送信があり、それらのペースも合わせたいと思っています。このため、RTOは、最後のトランザクションで最初のSTUN要求が発生するのと同じように、最初のトランザクションで最初の再送信が発生するように設定されます。図解： | |
| 最初のパケットの再送信 | |
| | | | | ------- + ------ ------- + ------ / \ / \ / \ / \ | |
| +-+ +-+ +-+ +-+ +-+ +-+ | A1 | | B1 | | C1 | | A2 | | B2 | | C2 | +-+ +-+ +-+ +-+ +-+ +-+ | |
| --- + ------- + ------- + ------- + ------- + ------- + ------ ------時間0 Ta 2Ta 3Ta 4Ta 5Ta | |
| この図では、送信される3つのトランザクションがあります（たとえば、候補者の収集の場合、3つのホスト候補/ STUNサーバーのペアがあります）。これらはトランザクションA、B、およびCです。再送信タイマーは、最初のトランザクション（パケットA2）の最初の再送信が時間3Taに送信されるように設定されます。 | |
| STUNは再送信で指数バックオフを使用するため、最初の再送信後の後続の再送信は、Taミリ秒間隔よりもさらに少ない頻度で発生します。 | |
| B.2。複数のベースを持つ候補者 | |
| セクション4.1.3では、同じトランスポートアドレスとベースを持つ候補の削除について説明します。ただし、トランスポートアドレスが同じでベースが異なる候補は冗長ではありません。エージェントは、同じIPアドレスとポートを持っているが、ベースが異なる2つの候補者を持つことができるのはいつですか？図10のトポロジを検討してください。 | |
| + ---------- + | スタンSrvr | + ---------- + | | ----- // \\ | | | B：net10 | | | \\ // ----- | | + ---------- + | NAT | + ---------- + | | ----- // \\ | A | | 192.168 / 16 | | | \\ // ----- | | | 192.168.1.100 ----- + ---------- + // \\ + ---------- + | | | | | | | 提供者| --------- | C：net10 | ----------- | 回答者| | | 10.0.1.100 | | 10.0.1.101 | | + ---------- + \\ // + ---------- + ----- | |
| 図10：異なるベースを持つ同一の候補 | |
| この場合、提供者はマルチホームです。ネット10プライベートネットワークであるネットワークCに1つのIPアドレス10.0.1.100があります。回答者はこの同じネットワーク上にあります。提供者は、192.168 / 16であるネットワークAにも接続されています。提供者のIPアドレスは、このネットワーク上で192.168.1.100です。このネットワークにはNATがあり、別のネット10プライベートネットワークであるネットワークBに接続していますが、ネットワークCには接続されていません。ネットワークBにはSTUNサーバーがあります。 | |
| 提供者は、ネットワークC（10.0.1.100:2498）のIPアドレスでホスト候補を取得し、ネットワークA（192.168.1.100:3344）のIPアドレスでホスト候補を取得します。192.168.1.100:3344から構成済みのSTUNサーバーに対してSTUNクエリを実行します。このクエリはNATを通過します。これにより、バインド10.0.1.100:2498が割り当てられます。STUNサーバーは、これをSTUNバインディング応答に反映します。これで、提供者は、ホスト候補（10.0.1.100:2498）と同一のトランスポートアドレスを持つサーバー反射候補を取得しました。ただし、サーバーの再帰候補のベースは192.168.1.100:3344であり、ホスト候補のベースは10.0.1.100:2498です。 | |
| B.3。<rel-addr>および<rel-port>属性の目的 | |
| 候補属性には、ICE自体ではまったく使用されない2つの値<rel-addr>および<rel-port>が含まれます。なぜ存在するのですか？ | |
| 含める理由は2つあります。1つ目は診断です。異なるタイプの候補者間の関係を知ることは非常に役立ちます。エージェントを含めることにより、エージェントはどのリレー候補がどの反射候補に関連付けられているかを知ることができ、それが特定のホスト候補に関連付けられています。ある候補者のチェックが成功し、他の候補者のチェックが成功しない場合、これはネットワークで何が起こっているかについて有用な診断を提供します。 | |
| 2番目の理由は、オフパスのQuality of Service（QoS）メカニズムに関係しています。ICEがPacketCable 2.0などの環境で使用される場合、プロキシは通常のSIP操作の実行に加えて、SIPメッセージのSDPを検査し、メディアトラフィックのIPアドレスとポートを抽出します。その後、ポリシーサーバーを介して、ネットワーク内のアクセスルーターと相互作用して、メディアフローの保証されたQoSを確立できます。このQoSは、5タプルに基づいてRTPトラフィックを分類し、保証されたレートを提供するか、Diffservコードポイントを適切にマークすることにより提供されます。レジデンシャルNATが存在し、中継候補がメディア用に選択されると、この中継候補は実際のTURNサーバーのトランスポートアドレスになります。そのアドレスは、QoS処理のためにパケットを分類するために使用されるアクセスルータの実際のトランスポートアドレスについては何も言いません。むしろ、TURNサーバーに向けたサーバー再帰候補が必要です。SDPで変換を実行することにより、プロキシはそのトランスポートアドレスを使用して、アクセスルーターからQoSを要求できます。 | |
| B.4。STUNユーザー名の重要性 | |
| ICEでは、短期の資格情報機能を使用して、STUNでメッセージ整合性を使用する必要があります。実際の短期資格情報は、SDPオファー/アンサー交換でユーザー名フラグメントを交換することにより形成されます。このメカニズムの必要性は、単なるセキュリティを超えています。そもそもICEが正しく動作するために実際に必要です。 | |
| エージェントL、R、およびZについて考えます。LおよびRは、10.0.0.0 / 8を使用しているプライベートエンタープライズ1内にあります。Zは、10.0.0.0 / 8を使用している民間企業2内にあります。結局のところ、RとZは両方ともIPアドレス10.0.1.1を持っています。LはZにオファーを送信します。Zはその答えとして、Lにホスト候補を提供します。この場合、それらの候補は10.0.1.1:8866および10.0.1.1:8877です。結局のところ、Rは同時にセッションに参加しており、ホスト候補として10.0.1.1:8866と10.0.1.1:8877も使用しています。これは、Zがそうであるように、RはそれらのポートでSTUNメッセージを受け入れる準備ができていることを意味します。Lは、STUN要求を10.0.1.1:8866に送信し、別の要求を10.0.1.1:8877に送信します。ただし、これらは予想どおりZに移動しません。代わりに、Rに移動します！Rが単にそれらに応答した場合、LはZとの接続を持っていると信じますが、実際には完全に異なるユーザーとの接続を持っていますが、R.これを修正するために、STUN短期資格情報メカニズムが使用されます。ユーザー名のフラグメントは十分にランダムであるため、RがZと同じ値を使用する可能性はほとんどありません。その結果、資格情報が無効であるため、RはSTUN要求を拒否します。本質的に、STUNユーザー名フラグメントは、特定のオファー/アンサーセッションにバインドされた一時的なホスト識別子の形式を提供します。 | |
| IPアドレスの非一意性の不幸な結果は、上記の例では、RがICEエージェントでさえない可能性があることです。それは任意のホストである可能性があり、STUNパケットが向けられるポートはそのホスト上の任意の一時ポートである可能性があります。このソケットでパケットをリッスンするアプリケーションがあり、使用中のプロトコルに関係なく不正な形式のパケットを処理する準備ができていない場合、そのアプリケーションの動作が影響を受ける可能性があります。幸いなことに、SDPで交換されるポートは一時的であり、通常動的または登録された範囲から引き出されるため、ホストRでサーバーを実行するためにポートが使用されず、むしろプロトコルのエージェント側である可能性が高くなります。これは、この範囲のポート使用の一時的な性質により、割り当てられたポートにヒットする可能性を減らします。ただし、問題が発生する可能性はありますが、そして、ネットワーク展開者はそれに備えておく必要があります。これはICE固有の問題ではないことに注意してください。漂遊パケットは、あらゆるタイプのプロトコル、特にパブリックインターネット上のプロトコルのポートにいつでも到着する可能性があります。そのため、この要件は、インターネットアプリケーションの一般的な設計ガイドラインを言い換えているだけです。あらゆるポートで未知のパケットに備えてください。 | |
| B.5。候補ペアの優先式 | |
| 候補ペアの優先順位は奇妙な形をしています。それは： | |
| ペアの優先度= 2 ^ 32 * MIN（G、D）+ 2 * MAX（G、D）+（G> D？1：0） | |
| どうしてこれなの？候補ペアがこの値に基づいてソートされる場合、結果のソートにはMAX / MINプロパティがあります。これは、2つの優先順位の最小値の減少に基づいてペアが最初にソートされることを意味します。最小優先度の値が同じペアの場合、最大優先度を使用してそれらの間でソートします。最大優先順位と最小優先順位が同じ場合、制御エージェントの優先順位が式の最後の部分でタイブレーカーとして使用されます。単一の候補の優先度は常に2 * 32未満であるため、2 * 32の係数が使用され、ペアの優先度は2つのコンポーネントの優先度の「連結」になります。これにより、MAX / MINソートが作成されます。MAX / MINは、特定のエージェントについて、優先度の高い候補がすべて試行されるまで、優先度の低い候補が使用されないようにします。 | |
| B.6。リモート候補属性 | |
| a = remote-candidates属性は、更新されたオファーと、候補を有効リストに移動したSTUNバインディング要求への応答との間の競合状態を排除するために存在します。この競合状態を図11に示します。メッセージ4を受信すると、エージェントLは候補ペアを有効なリストに追加します。単一のコンポーネントを持つ単一のメディアストリームしかない場合、エージェントLは更新されたオファーを送信できるようになりました。ただし、エージェントRからのチェックはまだ応答を生成しておらず、エージェントRは応答（メッセージ9）を取得する前に更新されたオファー（メッセージ7）を受信します。したがって、この特定のペアが有効であることはまだわかりません。この状態を解消するために、オファー側によって選択されたRの実際の候補（リモート候補）がオファー自体に含まれ、回答者はそれらのペアが検証されるまで回答を遅らせます。 | |
| エージェントAネットワークエージェントB |（1）オファー| | | ------------------------------------------> | |（2）回答| | | <------------------------------------------ | |（3）STUNリクエスト | | | ------------------------------------------> | |（4）STUN Res。| | | <------------------------------------------ | |（5）STUNリクエスト | | | <------------------------------------------ | |（6）STUN Res。| | | --------------------> | | | |ロスト| |（7）オファー| | | ------------------------------------------> | |（8）STUN Req。| | | < ------------------------------------------ | |（9）STUN Res。| | | ------------------------------------------> | |（10）回答| | | <------------------------------------------ | | |
| 図11：競合状態フロー | |
| B.7。キープアライブが必要な理由 | |
| 候補ペアでメディアが流れ始めたら、セッションの間中、中間NATでバインディングを維持する必要があります。通常、メディアストリームパケット自体（RTPなど）はこの目的を満たします。ただし、いくつかのケースでさらに議論する価値があります。まず、SIPなどの一部のRTPの使用法では、メディアストリームを「保留」にすることができます。これは、RFC 3264 [RFC3264]で定義されているように、SDPの「sendonly」または「inactive」属性を使用して実現されます。RFC 3264は、これらの場合にメディアの送信を停止するように実装に指示します。ただし、そうすると、NATバインディングがタイムアウトになり、メディアが保留にならない場合があります。 | |
| 第二に、テキスト会話[RFC4103]のペイロード形式など、一部のRTPペイロード形式は、間隔がNATバインディングタイムアウトを超えるほど頻繁にパケットを送信する場合があります。 | |
| 第三に、無音抑止が使用されている場合、無音の期間が長いと、メディア伝送がNATバインディングがタイムアウトするのに十分な時間停止する可能性があります。 | |
| これらの理由により、メディアパケット自体は信頼できません。ICEは、STUNバインディング指示を利用した単純な定期キープアライブを定義します。これにより、帯域幅の要件が非常に予測可能になり、QoSの予約に対応できるようになります。 | |
| B.8。なぜ仲間の再帰候補者を好むのですか？ | |
| セクション4.1.2では、候補のタイプとローカルプリファレンスに基づいて候補の優先度を計算する手順について説明します。そのセクションでは、ピア再帰候補のタイプ設定が常にサーバー再帰よりも高いことが必要です。何故ですか？理由は、セクション18のセキュリティの考慮事項に関係しています。攻撃者がエージェントに偽のピア反射候補を使用させるよりも、エージェントに偽のサーバー反射候補を使用させる方がはるかに簡単です。その結果、バインディング要求によるアドレス収集に対する攻撃は、ピアの再帰候補を優先することにより、ICEによって阻止されます。 | |
| B.9。更新されたオファーを送信する理由 | |
| セクション11.1では、メディアを送信するためのルールについて説明しています。両方のエージェントは、ICEチェックが完了すると、更新されたオファーを待たずにメディアを送信できます。確かに、更新された提案の唯一の目的は、SDPを「修正」して、メディアのデフォルトの宛先がICE手順に基づいてメディアの送信先と一致するようにすることです。 | |
| これは疑問を招きます-なぜ更新されたオファー/アンサー交換が必要なのですか？実際、純粋なオファー/アンサー環境ではそうではありません。オファー側とアンサー側は、ICEで使用する候補に同意し、候補の使用を開始できます。エージェント自体に関する限り、更新されたオファー/アンサーは新しい情報を提供しません。ただし、実際には、シグナリングパスに沿った多数のコンポーネントがSDP情報を調べます。これには、オフパスQoS予約を実行するエンティティ、ALGやSession Border Controller（SBC）などのNATトラバーサルコンポーネント、およびネットワークを受動的に監視する診断ツールが含まれます。これらのツールが変更なしで機能し続けるためには、SDPのコアプロパティである既存の メディアに使用されるアドレス（mおよびc行とrtcp属性）のICE以前の定義を保持する必要があります。このため、更新されたオファーを送信する必要があります。 | |
| B.10。キープアライブにバインド表示が使用される理由 | |
| メディアキープアライブについては、セクション10で説明します。これらのキープアライブは、両方のエンドポイントがICE対応の場合にSTUNを使用します。ただし、キープアライブは、バインディング要求トランザクション（応答を生成する）を使用するのではなく、指示を使用します。何故ですか？主な理由は、ネットワークQoSメカニズムに関係しています。メディアが流れ始めると、ネットワーク要素は、メディアストリームがかなり規則的な構造を持ち、ジッタの可能性がある一定の間隔で定期的なパケットを利用すると仮定します。エージェントがメディアパケットを送信しているときにバインド要求を受信した場合、エージェントはメディアパケットとともに応答パケットを生成する必要があります。これにより、メディアパケットを運ぶ5タプルの実際の帯域幅要件が増加し、これらのパケットの配信にジッタが発生します。 | |
| さらに、バインディング表示を使用すると、整合性を無効にしてパフォーマンスを向上させることができます。これは、PSTNゲートウェイやSBCなどの大規模なエンドポイントに役立ちます。 | |
| B.11。紛争解決メカニズムが必要な理由 | |
| ICEが2つのピア間で実行されると、1つのエージェントが制御され、もう1つのエージェントが制御されます。ルールは、実装タイプとオファー/アンサーの機能として定義され、誰が制御して誰が制御されるかを決定します。ただし、仕様では、場合によっては、双方が制御していると信じるか、両側が制御していると考えるかもしれないと述べています。どうしてこれが起こりますか？ | |
| 両方のエージェントが制御されていると信じる状態は、サードパーティのコール制御の場合に現れます。次のフローを検討してください。 | |
| AコントローラーB |（1）INV（）| | | <------------- | | |（2）200（SDP1）| | | -------------> | | | |（3）INV（）| | | -------------> | | |（4）200（SDP2）| | | <------------- | |（5）ACK（SDP2）| | | <------------- | | | |（6）ACK（SDP1）| | | -------------> | | |
| 図12：ロールの競合フロー | |
| このフローは、RFC 3725 [RFC3725]のフローIIIのバリエーションです。実際、生成されるメッセージが少ないため、フローIIIよりもうまく機能します。このフローでは、コントローラーはオファーレスINVITEをエージェントAに送信し、エージェントAはオファーSDP1で応答します。次に、エージェントはオファーレスINVITEをエージェントBに送信し、エージェントBにオファーSDP2で応答します。次に、コントローラーは各エージェントからのオファーを使用して回答を生成します。このフローを使用すると、ICEはエージェントAとエージェントBの間で実行されますが、両方がエージェントの役割を制御していると考えます。役割の競合解決手順を使用すると、ICEを使用するときにこのフローが適切に機能します。 | |
| 現時点では、両方のエージェントが制御されていると考える場合に生じる可能性のある文書化されたフローはありません。ただし、このカテゴリに適合するフローが発生した場合、競合解決手順によりこのケースが許可されます。 | |
| 著者の住所 | |
| ジョナサン・ローゼンバーグjdrosen.netニュージャージー州モンマスUS | |
| メール：[email protected] URI：http://www.jdrosen.net | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment