メインコンテンツまでスキップ

RFC 8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

  • ステータス: Proposed Standard
  • 発行日: January 2021
  • ストリーム: IETF
  • エラッタ: エラッタなし

Abstract (概要)​

このドキュメントは、「Trickle ICE」について説明しています。これは、インタラクティブ接続確立 (ICE) プロトコルの拡張機能であり、ICEエージェントが候補の収集中に接続性チェックを開始できるようにします。すべての候補を一度に交換するのではなく、時間をかけて段階的に候補を交換することで実現します。この方法により、通信セッションの確立プロセスを大幅に高速化できます。

Table of Contents (目次)​

Appendices (付録)​

1. Introduction (はじめに)​

インタラクティブ接続確立 (Interactive Connectivity Establishment, ICE) [RFC8445]は、リアルタイムトランスポートプロトコル (Real-time Transport Protocol, RTP) [RFC3550]のようなメディアプロトコルが、ネットワークアドレス変換器 (Network Address Translators, NAT)およびその他の中間ネットワーク要素の存在下でピア間のIPセッションを確立および維持できるようにするメカニズムを定義しています。ICEでは、候補(通信に使用できる可能性のあるトランスポートアドレス)がICEエージェントによって収集され、その後、通信セッションを確立する試みが実際に行われる前に完全に交換されます。

IPv6ネットワークが必要な場合、この手順の全体的な遅延は大きくなる可能性があります。また、一方または両方のエージェントに複数のネットワークインターフェース(例:ワイヤレスおよび有線)があり、単一のインターフェースに複数のアドレス(例:IPv4とIPv6)があり、STUN (Session Traversal Utilities for NAT) [RFC5389]またはTURN (Traversal Using Relays around NAT) [RFC5766]トラバーサルを使用するように設定されていることも一般的です。このようなシナリオでは、収集に相当な時間がかかる可能性があり、ユーザーおよびアプリケーションの観点から、コール全体の確立が長くなります。

このドキュメントで定義されている「Trickle ICE」プロトコルは、ICEを拡張することでセッション確立の遅延を削減します。ICEエージェントが利用可能になったときに候補情報を送信できるようにします(したがって「trickle」という用語、「滴る」または「徐々に流れる」を意味します)。このようにして、ICEエージェントは、ピアがすべての候補を収集するのを待つことなく、ピアから受信した候補との接続性チェックを即座に開始できます。

Trickle ICEは、いくつかのモードとそれらの使用を管理するルールも指定します。「Full Trickle」(フルトリクル)は最も一般的な動作モデルであり、ICEエージェントは候補を段階的または一度にすべて交換することを選択できます。「Half Trickle」(ハーフトリクル)は、一方のエージェントが候補を完全に交換し、もう一方のエージェントが段階的な候補交換に従事するモードです。このモードは、両方の当事者がこのプロトコルをサポートしているかどうかが不明なシナリオで特に役立ちます。

この仕様は、ICEエージェントの動作のみを定義し、候補収集メカニズム、および候補がICEエージェント間でどのように送信されるかの詳細には影響しません。ICE全般と同様に、この仕様はフォーマットとセマンティクスに焦点を当て、トランスポート方法には焦点を当てません。そのような特定の使用は別途定義されます(例えば、[RFC8840]はSIP [RFC3261]での使用を定義し、[XEP-0176]はXMPP [RFC6120]での使用を定義します)。

2. Terminology (用語)​

このドキュメントのキーワード「しなければならない (MUST)」、「してはならない (MUST NOT)」、「必須である (REQUIRED)」、「することになる (SHALL)」、「することはない (SHALL NOT)」、「すべきである (SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される (RECOMMENDED)」、「推奨されない (NOT RECOMMENDED)」、「してもよい (MAY)」、「選択できる (OPTIONAL)」は、BCP 14 [RFC2119] [RFC8174]に記載されているとおりに解釈されるものとします。ただし、ここに示すように、すべて大文字で表示される場合に限ります。

この仕様は、インタラクティブ接続確立 (Interactive Connectivity Establishment)のために[RFC8445]で定義されたすべての用語を使用します。さらに、以下の用語を定義します:

空のチェックリスト (Empty Checklist): 初期状態では候補ペアを含まないチェックリスト。候補ペアは段階的に追加されるためです。(このシナリオは通常のICEエージェントでは発生しません。エージェントがチェックリストのセットを作成する際、すべての候補ペアが既知であるためです。)

フルトリクル (Full Trickle): Trickle ICEエージェントの典型的な動作モードで、初期ICE記述には任意の数の候補(ゼロ候補を含む)を含めることができ、ハーフトリクルのように完全な候補生成を含める必要はありません。

ジェネレーション (Generation): ICEセッション内で送信されるすべての候補(特定のUsername FragmentとPasswordの組み合わせと相関する)。

ハーフトリクル (Half Trickle): Trickle ICEの動作モードで、開始者は初期ICE記述を作成して送信する前に、完全な候補生成を厳密に収集します。送信されると、これらの候補情報は通常のICEエージェントによって処理できます。通常のICEエージェントはTrickle ICEのサポートを必要としません。これにより、Trickle ICE互換の応答者は常に候補を収集し、接続性チェックを非ブロッキング方式で実行できるため、Trickle ICEの「約半分」の利点を提供します。ハーフトリクルメカニズムは主に、初期ICE記述を送信する前に応答者のTrickle ICEサポートを確認できない場合に使用することを目的としています。

ICE記述 (ICE Description): ICEエージェントを構成するために必要な、ICEセッションに関連するすべての属性(候補以外)。これには、Username Fragment、Password、およびその他の属性が含まれますが、これらに限定されません。

トリクル候補 (Trickled Candidates): Trickle ICEエージェントが初期ICE記述を送信または応答した後、しかし同じICEセッション内で送信する候補。トリクル候補は、候補収集および接続性チェックと並行して送信できます。

トリクリング (Trickling): トリクル候補を段階的に送信する行為。

3. Determining Support for Trickle ICE (Trickle ICEサポートの判定)​

Trickle ICEを完全にサポートするために、使用プロトコルは、実装がTrickle ICEがサポートされているかどうかを判断できるように、以下のメカニズムのいずれかを組み込むべきです (SHOULD):

  1. エージェントがセッションを開始する前にTrickle ICEサポートを確認できるように、機能検出方法を提供する(XMPPのService Discovery [XEP-0030]はそのようなメカニズムの1つです)。

  2. Trickle ICEサポートを必須にして、ユーザーエージェントがサポートを仮定できるようにする。

使用プロトコルが事前にTrickle ICEがサポートされているかどうかを判断する方法を提供していない場合、エージェントはセクション16で説明されているハーフトリクル手順を使用できます。

初期ICE記述を送信する前に、機能検出をサポートする使用プロトコルを実装するエージェントは、リモート側がTrickle ICEをサポートしているかどうかを確認しようとすることができます (MAY)。エージェントがリモート側がTrickle ICEをサポートしていないと判断した場合、通常のICEの使用に戻るか、セッション全体を放棄しなければなりません (MUST)。

使用プロトコルに機能検出方法が含まれていない場合でも、ユーザーエージェントは、'trickle'のICEオプションを通信することにより、ICE記述でTrickle ICEをサポートしていることを示すことができます。このトークンは、セッションレベル、またはデータストリームレベルの場合は各データストリームに対して提供されなければなりません (MUST)(エージェントは、一部のデータストリームではTrickle ICEサポートを指定し、他のデータストリームでは指定しないことがあってはなりません (MUST NOT))。注:ICEオプション'trickle'のエンコーディングと、それをピアに送信するために使用されるメッセージは、プロトコル固有です。例えば、SDP [RFC4566]のエンコーディングは[RFC8840]で定義されています。

専用の検出セマンティクスとハーフトリクルは、ICEセッションの開始前にのみ必要です。ICEセッションが確立され、両方の当事者のTrickle ICEサポートが確認された後、いずれのエージェントも後続の交換にフルトリクルを使用できます(セクション15も参照)。

4. Generating the Initial ICE Description (初期ICE記述の生成)​

ICEエージェントは、通信が間近であることを示す兆候がある(例えば、ユーザーインターフェースシグナルまたは通信セッションを開始する明示的な要求)とすぐに候補の収集を開始できます。通常のICEとは異なり、Trickle ICE実装では、候補をブロッキング方式で収集する必要はありません。したがって、ハーフトリクルを使用しない限り、開始エージェントができるだけ早く初期ICE記述を生成して送信すると、ユーザーエクスペリエンスが向上します(これにより、リモート側が候補の収集とトリクルを開始できます)。

開始者は、初期ICE記述を送信する際に、任意の候補の組み合わせを含めることができます (MAY)。これには、開始者が使用する予定のすべての候補を送信すること(ハーフトリクルのように)、公開アクセス可能なIPアドレスのみを送信すること(例えば、ファイアウォールの背後にないことがわかっているデータリレー上の候補)、または候補をまったく送信しないこと(この場合、開始者は応答者からの初期候補リストをより早く取得でき、応答者はより迅速に候補収集を開始できます)が含まれます。

初期ICE記述に含まれる候補については、優先順位と基礎 (Foundations)の計算、候補の冗長性の判定などの方法は、通常のICE [RFC8445]とまったく同じように機能します。

5. Handling the Initial ICE Description and Generating the Initial ICE Response (初期ICE記述の処理と初期ICE応答の生成)​

応答者が初期ICE記述を受信すると、まず、セクション3で説明されているように、ICE記述または開始者がTrickle ICEサポートを示しているかどうかを確認します。そうでない場合、応答者は通常のICE手順 [RFC8445]に従って初期ICE記述を処理しなければなりません (MUST)(または、ICEサポートがまったく検出されない場合は、使用プロトコルの関連処理ルール、例えばオファー/アンサー処理ルール [RFC3264]に従います)。ただし、Trickle ICEサポートが確認された場合、応答者は通常のICEサポートも自動的に仮定します。

初期ICE記述がTrickle ICEサポートを示している場合、応答者はその役割を決定し、候補の収集と優先順位付けを開始します。その際、応答者は初期ICE応答を送信することで応答し、開始者と応答者がチェックリストを形成して接続性チェックを開始できるようにします。

応答者は、候補収集中のいつでも初期ICE記述に応答できます。初期ICE応答には、すべての候補や候補なしを含む、任意の候補セットを含めることができます (MAY)。(候補を含めない利点は、初期ICE応答をできるだけ早く送信して、両方の当事者ができるだけ早くICEセッションがアクティブな交渉中であると見なせるようにすることです。)

セクション3で述べたように、SDPを使用する使用プロトコルでは、初期ICE応答は、ice-options属性に'trickle'トークンを含めることで、Trickle ICEサポートを示すことができます。

8. Performing Connectivity Checks (接続性チェックの実行)​

[RFC8445]で指定されているように、タイマーTaが起動するたびに、実行中 (Running)状態のチェックリストのみが、候補ペアの接続性チェックをスケジュールする際に選択されます。したがって、Trickle ICEエージェントは、候補ペアがリストに段階的に追加されると予想される限り、各チェックリストを実行中状態に維持しなければなりません (MUST)。その後、チェックリストの状態は[RFC8445]の手順に従って設定されます。

タイマーTaが起動して空のチェックリストが選択されるたびに、リストに対してアクションは実行されません。タイマーTaが再び期限切れになるのを待つことなく、エージェントは[RFC8445]のセクション6.1.4.2に従って、実行中状態の次のチェックリストを選択します。

[RFC8445]のセクション7.2.5.4では、接続性チェックトランザクションの完了時にエージェントがチェックリストとタイマー状態を更新する必要があります。このような更新中、通常のICEエージェントは、以下の両方の条件が満たされている場合、チェックリストの状態を失敗 (Failed)に設定します:

  • チェックリスト内のすべてのペアが失敗 (Failed)状態または成功 (Succeeded)状態のいずれかである。かつ

  • データストリームの各コンポーネントに対して、有効なリストに有効なペアが存在しない。

Trickle ICEでは、候補収集とトリクリングがまだ進行中である場合、上記の状況が頻繁に発生しますが、将来のチェックが成功する可能性は十分にあります。このため、Trickle ICEエージェントは、上記のリストに以下の条件を追加します:

  • すべての候補収集が完了し、エージェントが新しいローカル候補を発見することを予期していない。かつ

  • リモートエージェントが、セクション13で説明されているように、このチェックリストの候補終了指示を送信した。

9. Gathering and Conveying Newly Gathered Local Candidates (新しく収集されたローカル候補の収集と伝達)​

Trickle ICEエージェントが初期ICE記述と初期ICE応答を送信した後、STUN、TURN、およびその他の非ホスト候補収集メカニズムが結果を生成し始めるにつれて、新しいローカル候補の収集を継続する可能性が非常に高いです。エージェントがそのような新しい候補を発見するたびに、通常のICE手順に従って、その優先順位、タイプ、基礎 (Foundation)、およびコンポーネントIDを計算します。

次に、新しい候補は、既存のローカル候補のリストに対して冗長性がチェックされます。そのトランスポートアドレスとベースが既存の候補のものと一致する場合、冗長と見なされ、無視されます。これは、取得元のホストアドレスと一致するサーバー再帰候補(例えば、後者がパブリックIPv4アドレスの場合)で頻繁に発生します。通常のICEとは異なり、Trickle ICEエージェントは、その優先順位に関係なく、新しい候補を冗長と見なします。

次に、エージェントは新しく発見された候補をリモートエージェントに「トリクル」します。新しい候補の実際の配信は、SIPやXMPPなどの使用プロトコルによって処理されます。Trickle ICEは、これがどのように行われるかについて制限を課しません(たとえば、一部の使用プロトコルは、サーバー再帰候補の更新をトリクルしないことを選択し、代わりにピア再帰候補の発見に依存する場合があります)。

候補がトリクルされる場合、使用プロトコルは、各候補(およびセクション13で説明されているような候補終了指示)を、受信側のTrickle ICE実装に、送信された順序とまったく同じ順序で正確に1回配信しなければなりません (MUST)。使用プロトコルが候補の再送信を提供する場合、それらはICE実装から隠されなければなりません。

さらに、候補のトリクリングは特定のICEセッションに関連付けられなければならず、ICE再起動がある場合、以前のセッションの遅延更新がそのようなものとして認識され、受信側によって無視されるようにする必要があります。たとえば、SDPを介して候補を通知する使用プロトコルは、対応するa=candidate行にUsername Fragment値を含めることができます:

a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY

または、別の例として、WebRTC実装は、候補を表すJavaScriptオブジェクトにUsername Fragmentを含めることができます。

注:使用プロトコルは、両方の当事者が有効なICEセッション(Username FragmentとPasswordの組み合わせによって識別される)を示して合意するためのメカニズムを提供しなければならず、候補をペアリングするための一貫したビューを持つようにする必要があります。これは、ICE再起動の場合に特に重要です(セクション15を参照)。

注:使用プロトコルは、公開アクセス可能であることがわかっているエンティティに対してサーバー再帰候補をトリクルしないことを選択する場合があります。この場合、直接STUNバインディング要求を送信すると、シグナリングパスを通過するトリクル更新よりも速く宛先に到達する可能性が高いためです。

10. Pairing Newly Gathered Local Candidates (新しく収集されたローカル候補のペアリング)​

Trickle ICEエージェントがローカル候補を収集する際、候補ペアを形成しなければなりません。これはICE仕様 [RFC8445]で説明されているように機能しますが、以下の条件があります:

  1. Trickle ICEエージェントは、ローカル候補がリモート側にトリクルされるまで、ローカル候補をペアリングしてはなりません (MUST NOT)。

  2. エージェントがリモート側にローカル候補を送信したら、エージェントは、同じストリームとコンポーネントに対して現在既知のリモート候補があるかどうかをチェックします。ない場合、エージェントは単に新しい候補をローカル候補のリストに追加します(ペアリングせずに)。

  3. そうでない場合、エージェントがこのストリームとコンポーネントに対して既に1つ以上のリモート候補を学習している場合、ICE仕様 [RFC8445]で説明されているように、新しいローカル候補をペアリングしようとします。

  4. 新しく形成されたペアのローカル候補のタイプがサーバー再帰 (server-reflexive)の場合、エージェントは、関連する冗長性テストを完了する前に、ローカル候補をそのベースで置き換えなければなりません (MUST)。

  5. エージェントは、[RFC8445]のセクション6.1.2.4のルールに従って冗長なペアを削除しますが、既存のペアをチェックするのは、それらが待機 (Waiting)状態または凍結 (Frozen)状態の場合のみです。これにより、接続性チェックが進行中のペア(進行中 (In-Progress)状態)、または接続性チェックが既に最終的な結果を出しているペア(成功 (Succeeded)状態または失敗 (Failed)状態)の削除を回避します。

  6. 関連する冗長性テストを完了した後、ペアが追加されるチェックリストに既に候補ペアの最大数(デフォルトで[RFC8445]によると100)が含まれている場合、エージェントは、新しいペアのためのスペースを作るために、失敗状態のすべてのペアを拒否すべきです (SHOULD)。そのようなペアがない場合、エージェントは、ペアの数が最大ペア数に等しくなるまで、新しいペアのためのスペースを作るために、新しいペアよりも優先度が低いペアを拒否すべきです (SHOULD)。この処理は[RFC8445]のセクション6.1.2.5と一致しています。

11. Receiving Trickled Candidates (トリクル候補の受信)​

ICEセッション中のいつでも、Trickle ICEエージェントはリモートエージェントから新しい候補を受信する可能性があり、そこから候補ペアを形成しようとします。これはICE仕様 [RFC8445]で説明されているように機能しますが、以下の条件があります:

  1. エージェントは、同じストリームとコンポーネントに対して現在既知のローカル候補があるかどうかをチェックします。ない場合、エージェントは単に新しい候補をリモート候補のリストに追加します(ペアリングせずに)。

  2. そうでない場合、エージェントがこのストリームとコンポーネントに対して既に1つ以上のローカル候補を収集している場合、ICE仕様 [RFC8445]で説明されているように、新しいリモート候補をペアリングしようとします。

  3. 新しく形成されたペアのローカル候補のタイプがサーバー再帰 (server-reflexive)の場合、エージェントは、次のステップの冗長性チェックを完了する前に、ローカル候補をそのベースで置き換えなければなりません (MUST)。

  4. エージェントは、以下で説明するように冗長なペアを削除しますが、既存のペアをチェックするのは、それらが待機 (Waiting)状態または凍結 (Frozen)状態の場合のみです。これにより、接続性チェックが進行中のペア(進行中 (In-Progress)状態)、または接続性チェックが既に最終的な結果を出しているペア(成功 (Succeeded)状態または失敗 (Failed)状態)の削除を回避します。

    A. エージェントが2つのペア間で冗長性を見つけ、これらのペアの1つにタイプがピア再帰 (peer-reflexive)の新しく受信したリモート候補が含まれている場合、エージェントは、その候補を含むペアを拒否し、既存のペアの優先度を拒否されたペアの優先度に設定し、チェックリストを再ソートすべきです (SHOULD)。(このポリシーは、候補のシグナリングが受信エージェントにトリクルされる前にSTUNバインディング要求が受信されるリモートピア再帰候補に関する問題を排除するのに役立ちます。たとえば、ローカルエージェントとリモートエージェント間のペア優先度の異なるビューなど。同じ候補が、一方のエージェントではピア再帰として認識され、他方のエージェントではサーバー再帰として認識される可能性があるためです。)

    B. 次に、エージェントは[RFC8445]のセクション6.1.2.4で定義されたルールを適用します。

  5. 関連する冗長性テストを完了した後、ペアが追加されるチェックリストに既に候補ペアの最大数(デフォルトで[RFC8445]によると100)が含まれている場合、エージェントは、新しいペアのためのスペースを作るために、失敗状態のすべてのペアを拒否すべきです (SHOULD)。そのようなペアがない場合、エージェントは、ペアの数が最大ペア数に等しくなるまで、新しいペアのためのスペースを作るために、新しいペアよりも優先度が低いペアを拒否すべきです (SHOULD)。この処理は[RFC8445]のセクション6.1.2.5と一致しています。

12. Inserting Trickled Candidate Pairs into a Checklist (トリクル候補ペアのチェックリストへの挿入)​

ローカルエージェントが候補をトリクルし、そのローカル候補から候補ペアを形成した後(セクション9)、またはリモートエージェントがトリクル候補を受信し、そのリモート候補から候補ペアを形成した後(セクション11)、Trickle ICEエージェントは、このセクションで定義されているように、新しい候補ペアをチェックリストに追加します。

このセクションで定義されている手順の理解を容易にするために、エージェント内のすべてのチェックリストの次の表形式表現を検討してください(最初は、基礎の1つ、つまりf5に候補ペアがないことに注意してください):

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | F  | F  | F  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | F  | F  | F  | F  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | F  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | F  |    |    |    |    |
+-----------------+----+----+----+----+----+

表1: チェックリスト状態の例

Trickle ICEは、「静的」チェックリストセットに適用されるすべてのこれらのルールを保持します。これは、Trickle ICEエージェントが、すべての候補ペアが既に存在する状態で接続性チェックを開始する場合、候補ペアの状態が変化する方法が通常のICEエージェントと区別できないことを意味します。

もちろん、Trickle ICEとの主な違いは、接続性チェックの開始後に候補が到着する可能性があるため、チェックリストセットが動的に更新される可能性があることです。これが発生すると、エージェントは、以下に説明するように、新しく形成された候補ペアの状態を設定します。

ルール1: 新しく形成された候補ペアが、その基礎のすべての候補ペアの中で最も低いコンポーネントIDを持つ場合、またはコンポーネントIDが等しい場合は最も高い優先度を持つ場合(つまり、列の最も高い候補ペアである場合)、状態を待機 (Waiting)に設定します。

ルール2: その基礎に対して成功 (Succeeded)状態の候補ペアが少なくとも1つある場合、状態を待機 (Waiting)に設定します。

ルール3: 前のルールのいずれも適用されない場合、状態を凍結 (Frozen)に設定します。

候補ペアが待機状態に配置されても、[RFC8445]のルールは引き続き適用されるため、接続性チェックは実行中 (Running)状態のチェックリストからのみ実行されることに注意してください。したがって、候補ペアに対して実際に接続性チェックが実行されるまで、候補ペアが待機と凍結の間で複数回状態を変更する可能性があります。

13. Generating an End-of-Candidates Indication (候補終了指示の生成)​

特定のデータストリームに関連付けられたICEセッションのすべての候補収集が完了または期限切れになると、エージェントはそのセッションの「候補終了」(end-of-candidates)指示を生成し、シグナリングチャネルを介してリモートエージェントに送信します。指示の正確な形式は使用プロトコルに依存しますが、指示はジェネレーション(Username FragmentとPasswordの組み合わせ)を指定しなければなりません (MUST)。これにより、エージェントは候補終了指示を特定のICEセッションと関連付けることができます。指示は以下の方法で送信できます:

  • 開始要求の一部として(これは通常、ハーフトリクルの初期ICE記述の場合です)
  • エージェントがストリームに対して送信できる最後の候補と一緒に
  • スタンドアロン通知として(例えば、サーバーへのSTUNバインディング要求またはTURN割り当て要求が期限切れになり、エージェントがもはや積極的に候補を収集していない後)

候補終了指示をタイムリーに送信することは、あいまいさを回避し、ICE処理の完了を加速するために重要です。特に:

  • 制御されたTrickle ICEエージェントは、データストリームの収集を完了した後、候補終了指示を送信すべきです (SHOULD)。ただし、エージェントが収集を完了する機会を得る前にICE処理が完了する場合を除きます。
  • 制御するエージェントは、すべてのストリームの候補終了指示を送信する前にICE処理を完了してもかまいません (MAY)。ただし、制御するエージェントが、一貫性を保ち、ミドルボックスと制御されたエージェントにICE処理の状態を通知するために、可能な限り候補終了指示を送信することが推奨されます (RECOMMENDED)。

初期ICE記述またはそれへの応答の一部としてではなく、トリクリング中に候補終了指示を送信する場合、指示を1つ以上の特定のデータストリームに関連付ける方法を定義することは、使用プロトコルの責任です。

エージェントは、候補収集が実際に完了する前に候補終了指示を生成することも選択できます (MAY)。エージェントが収集が許容可能な時間を超えて続いていると判断した場合です。ただし、エージェントは、候補終了指示を送信した後に他の候補を送信してはなりません (MUST NOT)。

ハーフトリクルを実行する場合、エージェントは、追加の候補をトリクルする可能性がある場合(例えば、リモート側がTrickle ICEをサポートしていることが判明した場合)を除き、初期ICE記述と一緒に候補終了指示を送信すべきです (SHOULD)。

エージェントが候補終了指示を送信した後、セクション8で説明されているように、対応するチェックリストの状態を更新します。この時点以降、エージェントは、そのICEセッション内で新しい候補をトリクルしてはなりません (MUST NOT)。したがって、ネゴシエーションに新しい候補を追加することは、ICE再起動によってのみ可能です(セクション15を参照)。

この仕様は、ICE処理を完了するための通常のICEセマンティクスを置き換えるものではありません。したがって、候補終了指示が送信されても、エージェントはペアの指名を続ける必要があります。さらに、コンポーネントとデータストリームに対してペアが指名されている場合、すべてのストリームの候補終了指示が受信されていなくても、ICE処理は完了してもかまいません (MAY)。すべての場合において、エージェントは、[RFC8445]のセクション8.1.1で説明されているように候補ペアが指名された後、ICEセッション内で新しい候補をトリクルしてはなりません (MUST NOT)。

14. Receiving an End-of-Candidates Indication (候補終了指示の受信)​

候補終了指示を受信すると、エージェントはチェックリストの状態を更新でき、各データストリームの各コンポーネントに有効なペアが存在しない場合、ICE処理が失敗したと判断できます。また、エージェントは、候補ペアが検証されたが、TURNなどの優先度の低いトランスポートを使用している場合、ICE処理の完了を加速することもできます。このような状況では、実装は、より高い優先度の候補が受信されるかどうかを待つことを選択できます (MAY)。この場合、候補終了指示は、そのような候補が来ないという通知を提供します。

エージェントが特定のデータストリームの候補終了指示を受信すると、セクション8に従って関連するチェックリストの状態を更新します(これにより、一部のチェックリストが失敗としてマークされる可能性があります)。更新後もチェックリストがまだ実行中 (Running)状態にある場合、エージェントは候補終了指示が受信されたことを記録し、将来のチェックリスト更新でそれを考慮に入れます。

エージェントが候補終了指示を受信した後、そのデータストリームまたはデータセッションに対して新しく受信した候補を無視しなければなりません (MUST)。

15. Subsequent Exchanges and ICE Restarts (後続の交換とICE再起動)​

候補終了指示を送信する前に、いずれかのエージェントは、ユーザープロトコルで許可されている時点で後続の候補情報を送信してもかまいません (MAY)。これが発生すると、エージェントは[RFC8445]のセマンティクス(例えば、Username FragmentとPasswordの組み合わせのチェック)を使用して、新しい候補情報がICE再起動を必要とするかどうかを判断します。

ICE再起動が発生した場合、エージェントは、サポートが以前に決定されていれば、Trickle ICEが引き続きサポートされていると仮定できます。したがって、サポートが機能検出方法によって決定された初期ICE記述の交換と同様に、Trickle ICEの動作に従事できます。

16. Half Trickle (ハーフトリクル)​

ハーフトリクルでは、開始者は、使用可能だが必ずしも完全ではない候補生成と共に初期ICE記述を送信します。これにより、ICE記述が通常のICE応答者によって処理できることが保証され、主に初期ICE記述を送信する前にTrickle ICEサポートを確認できない場合に使用することを目的としています。初期ICE記述はTrickle ICEサポートを示しているため、応答者は完全な候補生成よりも少ないもので応答し、その後残りをトリクルできます。ハーフトリクルの初期ICE記述には候補終了指示が含まれる場合がありますが、トリクルサポートが確認されれば、開始者は候補終了指示を送信する前に追加の候補をトリクルすることを選択できるため、これは必須ではありません。

ハーフトリクルメカニズムは、エージェントが事前にリモート側がTrickle ICEをサポートしているかどうかを確認する方法がない場合に使用できます。初期ICE記述には完全な候補生成が含まれているため、通常のICEエージェントによって処理できます。一方、Trickle ICE対応エージェントは、この仕様で定義されている最適化を使用できます。これにより、最初のケースではネゴシエーションの失敗を回避し、2番目のケースではTrickle ICEの約半分の利点を提供します。

ハーフトリクルの使用は、ICE記述の初期交換中にのみ必要です。両方の当事者が相手からICE記述を受信した後、それぞれはTrickle ICEサポートを確実に判断し、すべての後続の交換に使用できます(セクション15を参照)。

場合によっては、ハーフトリクルの使用は、ユーザーエクスペリエンスの観点から半分以上の改善をもたらす可能性があります。これは、エージェントが、ユーザーがまもなくインタラクションを開始することを示すユーザーインターフェースの兆候(例えば、キーボード上のアクティビティや電話が持ち上げられること)に基づいて候補の収集を開始する場合に発生する可能性があります。これは、エージェントが実際に候補情報を送信する必要がある前に、候補収集の一部またはすべてが完了する可能性があることを意味します。応答者が候補をトリクルできるため、両方のエージェントは接続性チェックを開始し、通常のICEよりも早く、場合によってはフルトリクルと同じくらい早くICE処理を完了できます。

ただし、そのような予測は常に可能であるとは限りません。たとえば、通信が中心的な機能ではない多目的ユーザーエージェントまたはWebRTC Webページ(例えば、主要機能に問題がある場合にサポートラインに電話する)では、通話の意図と他のユーザーアクティビティを区別する方法が必ずしもありません。このような場合、フルトリクルの使用が最も理想的なユーザーエクスペリエンスを提供する可能性が高いです。それでも、ハーフトリクルの使用は、応答者により良いエクスペリエンスを提供するため、通常のICEよりも改善されます。

18. Requirements for Using Protocols (プロトコル使用の要件)​

Trickle ICEの使用を完全に可能にするために、この仕様は使用プロトコルに対して以下の要件を定義します。

  • 使用プロトコルは、ICEセッションが開始される前に当事者がTrickle ICEサポートを宣伝および発見するための手段を提供すべきです (SHOULD)(セクション3を参照)。

  • 使用プロトコルは、初期ICE記述を送信した後に、段階的に(つまり、「トリクル」)追加の候補を送信する方法を提供しなければなりません (MUST)(セクション9を参照)。

  • 使用プロトコルは、各トリクル候補または候補終了指示を、送信された順序とまったく同じ順序で正確に1回配信しなければなりません (MUST)(セクション9を参照)。

  • 使用プロトコルは、両方の当事者が有効なICEセッションを示して合意するためのメカニズムを提供しなければなりません (MUST)(セクション9を参照)。

  • 使用プロトコルは、当事者が候補終了指示を伝達する方法を提供しなければならず、指示が適用される特定のICEセッションを指定しなければなりません (MUST)(セクション13を参照)。

19. IANA Considerations (IANAに関する考慮事項)​

IANAは、[RFC6336]で定義された手順に従って、「Interactive Connectivity Establishment (ICE)レジストリ」の「ICEオプション」サブレジストリに次のICEオプションを登録しました。

ICEオプション: trickle

連絡先: IESG <[email protected]>

変更管理者: IESG

説明: 'trickle'のICEオプションは、ICE候補の段階的通信のサポートを示します。

参照: RFC 8838

20. Security Considerations (セキュリティに関する考慮事項)​

この仕様は、そのセマンティクスのほとんどを[RFC8445]から継承しており、したがって、そこで説明されているすべてのセキュリティに関する考慮事項がTrickle ICEに適用されます。

端末デバイス上のホストアドレスの開示に関連するプライバシーへの影響が懸念される場合(たとえば、[RFC8828]および[RFC8445]のセクション19での議論を参照)、エージェントは候補を含まないICE記述を生成し、ホストアドレスを開示しない候補(たとえば、リレー候補)のみをトリクルできます。

Appendix A. Interaction with Regular ICE (通常のICEとの相互作用)​

ICEプロトコルは、できるだけ多くのネットワーク環境で動作し、適応できるように十分に柔軟に設計されています。この柔軟性にもかかわらず、[RFC8445]で指定されているICE単体ではTrickle ICEをサポートしていません。このセクションでは、候補のトリクリングがICEとどのように相互作用するかを説明します。

[RFC8445]は、ICEエージェントが実行中 (Running)状態にある間にチェックリストとタイマー状態を更新するために必要な条件を説明しています。これらの条件はトランザクション完了時にチェックされ、その1つは次のように規定しています:

チェックリストに関連付けられたデータストリームの各コンポーネントに対して、有効なリストに有効なペアがない場合、チェックリストの状態は失敗 (Failed)に設定されます。

これは問題となり、多くのシナリオでICE処理が早期に失敗する可能性があります。以下のケースを考えてみましょう:

シナリオ1: プライベートアドレスブロックの衝突​

  1. アリスとボブは両方とも、ネットワークアドレス変換 (NAT)を備えた異なるネットワークに位置しています。アリスとボブ自体は異なるアドレスを持っていますが、両方のネットワークは同じプライベートインターネットブロック(例えば、[RFC1918]で指定されている「20ビットブロック」172.16/12)を使用しています。
  2. アリスはボブに候補172.16.0.1を送信しますが、これはボブのネットワーク上の既存のホストにも対応しています。
  3. ボブは自分のホスト候補と172.16.0.1から候補ペアを作成し、このペアをチェックリストに配置してチェックを開始します。
  4. これらのチェックは、ボブのネットワーク上の172.16.0.1のホストに到達し、ICMPエラー「ポート到達不能」で応答します。[RFC8445]によると、ボブはトランザクションを失敗としてマークします。

この時点で、チェックリストには失敗したペアのみが含まれており、有効なリストは空です。これにより、データストリームおよび潜在的にICE処理全体が失敗しますが、Trickle ICEエージェントが後で成功する可能性のある候補を送信する可能性があります。

シナリオ2: アドレスファミリーの不一致​

アリスの初期ICE記述に、ボブが収集した候補のいずれからも到達不能であると判断できる候補のみが含まれている場合、同様の競合状態が発生します(たとえば、ボブの候補にIPv4アドレスのみが含まれ、アリスから受信した最初の候補がIPv6アドレスである場合)。

シナリオ3: 非Trickle ICE相互作用​

非Trickle ICE実装がTrickle ICE実装とのインタラクションを開始する場合、別の潜在的な問題が発生する可能性があります。以下のケースを考えてみましょう:

  1. アリスのクライアントは非Trickle ICE実装を持っています。
  2. ボブのクライアントはTrickle ICEをサポートしています。
  3. アリスとボブはアドレス依存フィルタリング [RFC4787]を備えたNATの背後にいます。
  4. ボブには2つのSTUNサーバーがありますが、そのうちの1つは現在到達不能です。

ボブのエージェントがアリスの初期ICE記述を受信した後、接続性チェックを即座に開始します。候補の収集も開始しますが、到達不能なSTUNサーバーのために時間がかかります。ボブの応答が準備されてアリスに送信されるまでに、ボブの接続性チェックが失敗している可能性があります:アリスがボブの応答を取得するまで、接続性チェックを開始してNATに穴を開けることができません。したがって、NATは、ボブのチェックを未知のエンドポイントからのものとしてフィルタリングします。