4. Sending the Initial Offer (初期オファーの送信)

オファー/アンサー交換で初期オファーを送信するために、エージェントは (1) 候補を収集し、(2) それらに優先順位を付け、(3) 冗長な候補を排除し、(4) デフォルトの候補を選択し、そして (5) SDP オファーを作成して送信しなければなりません。これら 5 つのステップのうち最後を除くすべては、フル実装とライト実装で異なります。

4.1. Full Implementation Requirements (フル実装の要件)

4.1.1. Gathering Candidates (候補の収集)

エージェントは、通信が差し迫っていると判断したときに候補を収集します。オファーラーは、ユーザーインターフェイスの合図に基づいて、またはセッションを開始するための明示的な要求に基づいてこれを行うことができます。すべての候補はトランスポートアドレスです。また、タイプとベースもあります。この仕様によって定義され、収集される 4 つのタイプがあります。ホスト候補、サーバー反射候補、ピア反射候補、およびリレー候補です。サーバー反射候補は STUN または TURN を使用して収集され、リレー候補は TURN を通じて取得されます。ピア反射候補は、接続チェックの結果として、ICE の後のフェーズで取得されます。候補のベースは、その候補を使用するときにエージェントが送信しなければならない候補です。

4.1.1.1. Host Candidates (ホスト候補)

最初のステップは、ホスト候補を収集することです。ホスト候補は、ホスト上のインターフェイス（物理または仮想、VPN インターフェイスを含む）に接続された IP アドレス上のポート（通常は一時的）にバインドすることによって取得されます。

エージェントが使用したい各 UDP メディアストリームについて、エージェントは、ホストが持つ各 IP アドレス上のメディアストリームの各コンポーネントの候補を取得すべきです (SHOULD)。特定の IP アドレス上の UDP ポートにバインドすることによって各候補を取得します。ホスト候補（および実際にはすべての候補）は、常にそれが候補である特定のコンポーネントに関連付けられています。各コンポーネントには、コンポーネント ID と呼ばれる ID が割り当てられています。RTP ベースのメディアストリームの場合、RTP 自体のコンポーネント ID は 1 であり、RTCP のコンポーネント ID は 2 です。エージェントが RTCP を使用している場合、その候補を取得しなければなりません (MUST)。エージェントが RTP と RTCP の両方を使用している場合、エージェントが K 個の IP アドレスを持っていると、最終的に 2*K 個のホスト候補を持つことになります。

各ホスト候補のベースは、候補自体に設定されます。

4.1.1.2. Server Reflexive and Relayed Candidates (サーバー反射およびリレー候補)

エージェントはリレー候補を取得すべきであり (SHOULD)、サーバー反射候補を取得すべきです (SHOULD)。これらの要件は、プロバイダーのバリエーションを可能にするために SHOULD の強度になっています。STUN および TURN サーバーの使用は、エージェントがパブリックインターネットや閉域網の外部のエンドポイントに接続されない閉域網では不要な場合があります。このような場合、フル実装は、デュアルスタックまたはマルチホームのエージェントがホスト候補を選択するために使用されます。TURN サーバーの使用は高価であり、ICE が使用されている場合、両方のエンドポイントがアドレスとポートに依存するマッピングを実行する NAT の背後にある場合にのみ利用されます。その結果、一部の展開ではこのユースケースを重要ではないと考え、TURN サーバーを使用しないことを選択する場合があります。エージェントがサーバー反射またはリレー候補を収集しない場合、機能は実装し、構成によって無効にすることが推奨されます (RECOMMENDED)。そうすれば、将来条件が変化した場合に構成によって再度有効にすることができます。

エージェントがリレー候補とサーバー反射候補の両方を収集している場合、TURN サーバーを使用します。サーバー反射候補のみを収集している場合は、STUN サーバーを使用します。

次に、エージェントは各ホスト候補を、構成されているか、何らかの手段で発見した STUN または TURN サーバーとペアにします。STUN または TURN サーバーが構成されている場合、ドメイン名を構成し、[RFC5389] の DNS 手順（"stun" サービスの SRV レコードを使用）を使用して STUN サーバーを発見し、[RFC5766] の DNS 手順（"turn" サービスの SRV レコードを使用）を使用して TURN サーバーを発見することが推奨されます (RECOMMENDED)。

この仕様では、単一の STUN または TURN サーバーの使用のみを考慮しています。その単一の STUN または TURN サーバーに複数の選択肢がある場合（たとえば、DNS レコードを通じて学習され、複数の結果が返される場合）、エージェントは特定のセッションのすべての候補に対して（その IP アドレスに基づいて）単一の STUN または TURN サーバーを使用すべきです (SHOULD)。これにより、ICE のパフォーマンスが向上します。結果は、ホスト候補と STUN または TURN サーバーのペアのセットになります。次に、エージェントは 1 つのペアを選択し、そのホスト候補からサーバーに Binding または Allocate リクエストを送信します。STUN サーバーへの Binding リクエストは認証されず、応答内の ALTERNATE-SERVER 属性は無視されます。エージェントは、[RFC5389] で定義されている Binding リクエストの下位互換モードをサポートしなければなりません (MUST)。Allocate リクエストは、クライアントが他の手段で取得した長期的な資格情報を使用して認証されるべきです (SHOULD)。

その後、Ta ミリ秒ごとに、エージェントは別の新しい STUN または TURN トランザクションを生成できます。このトランザクションは、回復可能なエラー（認証の失敗など）で失敗した以前のトランザクションの再試行か、新しいホスト候補と STUN または TURN サーバーのペアのトランザクションのいずれかです。エージェントは、Ta ミリ秒に 1 回より頻繁にトランザクションを生成すべきではありません (SHOULD NOT)。Ta および STUN 再送信タイマー RTO の設定方法に関するガイダンスについては、セクション 16 を参照してください。

エージェントは Binding または Allocate 応答を受信します。成功した Allocate 応答は、エージェントにサーバー反射候補（マップされたアドレスから取得）と XOR-RELAYED-ADDRESS 属性のリレー候補を提供します。サーバーがリソース不足のために Allocate リクエストが拒否された場合、エージェントは代わりに Binding リクエストを送信してサーバー反射候補を取得すべきです (SHOULD)。Binding 応答は、エージェントにサーバー反射候補のみを提供します（これもマップされたアドレスから取得されます）。サーバー反射候補のベースは、Allocate または Binding リクエストが送信されたホスト候補です。リレー候補のベースは、その候補自体です。リレー候補がホスト候補と同一である場合（これはまれに発生する可能性があります）、リレー候補は破棄されなければなりません (MUST)。

4.1.1.3. Computing Foundations (ファンデーションの計算)

最後に、エージェントは各候補にファンデーションを割り当てます。ファンデーションは、セッション内でスコープされた識別子です。次のすべてが当てはまる場合、2 つの候補は同じファンデーション ID を持たなければなりません (MUST)：

• それらは同じタイプ（ホスト、リレー、サーバー反射、またはピア反射）である。
• それらのベースは同じ IP アドレスを持っている（ポートは異なっていてもよい）。
• 反射およびリレー候補の場合、それらを取得するために使用された STUN または TURN サーバーは同じ IP アドレスを持っている。
• それらは同じトランスポートプロトコル（TCP、UDP など）を使用して取得された。

同様に、タイプが異なる場合、ベースの IP アドレスが異なる場合、それらを取得するために使用された STUN または TURN サーバーの IP アドレスが異なる場合、またはトランスポートプロトコルが異なる場合、2 つの候補は異なるファンデーションを持たなければなりません (MUST)。

4.1.1.4. Keeping Candidates Alive (候補の維持)

サーバー反射およびリレー候補が割り当てられると、セクション 8.3 で説明されているように、ICE 処理が完了するまでそれらを維持しなければなりません (MUST)。Binding リクエストを通じて学習されたサーバー反射候補の場合、バインディングは、サーバーへの追加の Binding リクエストによって維持されなければなりません (MUST)。割り当ての更新は、[RFC5766] で説明されているように、Refresh トランザクションを使用して行われます。Refresh リクエストは、サーバー反射候補も更新します。

4.1.2. Prioritizing Candidates (候補の優先順位付け)

優先順位付けプロセスにより、各候補に優先順位が割り当てられます。メディアストリームの各候補は、1 から (2**31 - 1) の間の正の整数でなければならない (MUST) 一意の優先順位を持たなければなりません (MUST)。この優先順位は、ICE が接続チェックの順序と候補の相対的な優先度を決定するために使用されます。

エージェントは、セクション 4.1.2.1 の式を使用してこの優先順位を計算し (SHOULD)、セクション 4.1.2.2 のガイドラインを使用してそのパラメータを選択すべきです。エージェントが異なる式を使用することを選択した場合、両方のエージェントがチェックで調整されないため、ICE の収束に時間がかかります。

4.1.2.1. Recommended Formula (推奨される式)

式を使用する場合、エージェントは、各タイプの候補（サーバー反射、ピア反射、リレー、およびホスト）の優先度を決定し、エージェントがマルチホームの場合は IP アドレスの優先度を選択することによって優先順位を計算します。これら 2 つの優先度を組み合わせて、候補の優先順位を計算します。その優先順位は、次の式を使用して計算されます。

priority = (2^24)*(type preference) +
           (2^8)*(local preference) +
           (2^0)*(256 - component ID)

タイプ優先度 (type preference) は、0 から 126 までの整数でなければならず (MUST)、候補のタイプの優先度を表します（タイプはローカル、サーバー反射、ピア反射、およびリレーです）。126 が最も高い優先度で、0 が最も低い優先度です。値を 0 に設定すると、このタイプの候補は最後の手段としてのみ使用されることを意味します。同じタイプのすべての候補のタイプ優先度は同一でなければならず (MUST)、異なるタイプの候補の場合は異なっていなければなりません (MUST)。ピア反射候補のタイプ優先度は、サーバー反射候補のタイプ優先度よりも高くなければなりません (MUST)。セクション 4.1.1 の手順に基づいて収集された候補がピア反射候補になることは決してないことに注意してください。これらのタイプの候補は、ICE によって実行される接続チェックから学習されます。

ローカル優先度 (local preference) は、0 から 65535 までの整数でなければなりません (MUST)。これは、エージェントがマルチホームの場合に、候補が取得された特定の IP アドレスの優先度を表します。65535 は最も高い優先度を表し、0 は最も低い優先度を表します。単一の IP アドレスしかない場合、この値は 65535 に設定すべきです (SHOULD)。より一般的には、特定のメディアストリームの特定のコンポーネントに対して同じタイプを持つ複数の候補がある場合、ローカル優先度はそれぞれに対して一意でなければなりません (MUST)。この仕様では、これはマルチホームホストでのみ発生します。デュアルスタックであるためにホストがマルチホームである場合、ローカル優先度は、RFC 3484 [RFC3484] で説明されている IP アドレスの優先順位値と同じに設定すべきです (SHOULD)。

コンポーネント ID は候補のコンポーネント ID であり、1 から 256 の間でなければなりません (MUST)。

4.1.2.2. Guidelines for Choosing Type and Local Preferences (タイプとローカル優先度を選択するためのガイドライン)

タイプとローカル優先度の値を選択する 1 つの基準は、TURN サーバー、VPN サーバー、または NAT などのメディア仲介の使用です。メディア仲介を使用する場合、メディアがその候補に送信されると、受信される前にまずメディア仲介を通過します。リレー候補は、メディア仲介を含む候補の 1 つのタイプです。もう 1 つは、VPN インターフェイスから取得されたホスト候補です。メディアがメディア仲介を通過すると、送信から受信までの遅延が増加する可能性があります。追加のルーターホップが発生する可能性があるため、パケット損失が増加する可能性があります。メディアはプロバイダーが運営するメディア仲介に出入りするため、サービスの提供コストが増加する可能性があります。これらの懸念が重要な場合、リレー候補のタイプ優先度はホスト候補よりも低くすべきです (SHOULD)。推奨値 (RECOMMENDED) は、ホスト候補が 126、サーバー反射候補が 100、ピア反射候補が 110、リレー候補が 0 です。さらに、エージェントがマルチホームで複数の IP アドレスを持っている場合、VPN インターフェイスからのホスト候補のローカル優先度は 0 の優先順位を持つべきです (SHOULD)。

優先度を選択するための別の基準は、IP アドレスファミリです。ICE は IPv4 と IPv6 の両方で機能します。したがって、デュアルスタックホストが IPv6 接続を優先し、v6 ネットワークが切断された場合（たとえば、6to4 リレーの障害など）に IPv4 にフォールバックできるようにする移行メカニズムを提供します [RFC3056]。また、ネイティブ IPv6 アドレスと 6to4 アドレスの両方を持つホストにも役立ちます。このような場合、v6 アドレスに高いローカル優先度を割り当て、次に 6to4 アドレス、次に v4 アドレスを割り当てることができます。これにより、サイトはネイティブ v6 アドレスをすぐに取得して使用を開始できますが、まだネイティブ v6 接続がない他のサイトのエージェントと通信する場合は、6to4 アドレスにフォールバックできます。

優先度を選択するための別の基準はセキュリティです。ユーザーが在宅勤務者であり、企業ネットワークとローカルホームネットワークに接続されている場合、ユーザーは、企業内で通信する場合は企業ネットワーク上に維持するために VPN 経由で音声トラフィックをルーティングすることを好むかもしれませんが、企業の外部のユーザーと通信する場合はローカルネットワークを使用することを好むかもしれません。このような場合、VPN アドレスは他のどのアドレスよりも高いローカル優先度を持ちます。

優先度を選択するための別の基準は、トポロジ認識です。これは、仲介を使用する候補にとって最も便利です。その場合、エージェントが仲介の自身へのトポロジ的な近接性に関する知識を事前構成または動的に発見している場合、それを使用して、より近い仲介から取得された候補に高いローカル優先度を割り当てることができます。

4.1.3. Eliminating Redundant Candidates (冗長な候補の排除)

次に、エージェントは冗長な候補を排除します。候補のトランスポートアドレスが別の候補と等しく、そのベースがその別の候補のベースと等しい場合、その候補は冗長です。2 つの候補が同じトランスポートアドレスを持ちながら異なるベースを持つ可能性があることに注意してください。これらは冗長とは見なされません。多くの場合、エージェントが NAT の背後にない場合、サーバー反射候補とホスト候補は冗長になります。エージェントは、優先順位の低い冗長な候補を排除すべきです (SHOULD)。

4.1.4. Choosing Default Candidates (デフォルト候補の選択)

候補が非 ICE ピアからのメディアのターゲットになる場合、その候補はデフォルトであると言われます。そのターゲットはデフォルト宛先 (DEFAULT DESTINATION) と呼ばれます。ICE 対応ピアと通信するときに ICE アルゴリズムによってデフォルト候補が選択されない場合、メディアのデフォルト宛先が ICE によって選択された候補と一致するように SDP を「修正」するために、ICE 処理の完了後に更新されたオファー/アンサーが必要になります。ICE がたまたまデフォルト候補を選択した場合、更新されたオファー/アンサーは必要ありません。

エージェントは、使用中の各メディアストリームの各コンポーネントに対して 1 つずつ、デフォルトとして候補のセットを選択しなければなりません (MUST)。ポートが 0 でない場合（RFC 3264 でメディアストリームを拒否するために使用されます）、メディアストリームは使用中です。したがって、a=inactive [RFC4566] としてマークされているか、帯域幅の値が 0 であっても、メディアストリームは使用中です。

デフォルト候補は、それらの候補が連絡先のピアと機能する可能性に基づいて選択されることが推奨されます (RECOMMENDED)。デフォルト候補は、リレー候補（リレー候補が利用可能な場合）、サーバー反射候補（サーバー反射候補が利用可能な場合）、そして最後にホスト候補であることが推奨されます (RECOMMENDED)。

4.2. Lite Implementation Requirements (ライト実装の要件)

ライト実装はホスト候補のみを利用します。ライト実装は、各メディアストリームの各コンポーネントに対して、0 または 1 つの IPv4 候補を割り当てなければなりません (MUST)。0 または複数の IPv6 候補を割り当てることができますが (MAY)、ホストが使用する各 IPv6 アドレスにつき 1 つ以下です。各メディアストリームの各コンポーネントに対して IPv4 候補は 1 つしか存在できないため、エージェントが複数の IPv4 アドレスを持っている場合、候補を割り当てるために 1 つを選択しなければなりません (MUST)。ホストがデュアルスタックの場合、1 つの IPv4 候補と 1 つのグローバル IPv6 アドレスを割り当てることが推奨されます (RECOMMENDED)。ライト実装では、ICE を使用して候補の中から動的に選択することはできません。したがって、特定のスコープから複数の候補を含めることは推奨されません (NOT RECOMMENDED)。接続チェックのみが、一方のアドレスを使用するか他方を使用するかを真に決定できるためです。

各コンポーネントには、コンポーネント ID と呼ばれる ID が割り当てられています。RTP ベースのメディアストリームの場合、RTP 自体のコンポーネント ID は 1 であり、RTCP のコンポーネント ID は 2 です。エージェントが RTCP を使用している場合、その候補を取得しなければなりません (MUST)。

各候補にはファンデーションが割り当てられます。異なる IP アドレスから割り当てられた 2 つの候補の場合、ファンデーションは異なっていなければならず (MUST)、それ以外の場合は同じでなければなりません (MUST)。各 IP アドレスごとに増加する単純な整数で十分です。さらに、各候補には、同じメディアストリームのすべての候補の中で一意の優先順位を割り当てなければなりません (MUST)。この優先順位は、次と等しくあるべきです (SHOULD)：

priority = (2^24)*(126) +
           (2^8)*(IP precedence) +
           (2^0)*(256 - component ID)

ホストが v4 のみの場合、IP 優先順位を 65535 に設定すべきです (SHOULD)。ホストが v6 またはデュアルスタックの場合、IP 優先順位は RFC 3484 [RFC3484] で説明されている IP アドレスの優先順位値であるべきです (SHOULD)。

次に、エージェントは各メディアストリームの各コンポーネントのデフォルト候補を選択します。ホストが IPv4 のみの場合、各メディアストリームの各コンポーネントに対して候補は 1 つしかないため、その候補がデフォルトになります。ホストが IPv6 またはデュアルスタックの場合、デフォルトの選択はローカルポリシーの問題です。このデフォルトは、ピアで使用される可能性が最も高い候補になるように選択すべきです (SHOULD)。IPv6 のみのホストの場合、これは通常、グローバルにスコープされた IPv6 アドレスになります。デュアルスタックホストの場合、IPv4 アドレスが推奨されます (RECOMMENDED)。

4.3. Encoding the SDP (SDP のエンコード)

SDP をエンコードするプロセスは、フル実装とライト実装の間で同じです。

エージェントは、使用したい各メディアストリームの m 行を含めます。SDP 内のメディアストリームの順序は ICE に関連しています。ICE は最初の m 行に対して最初に接続チェックを実行するため、メディアはそのストリームに対して最初に流れることができます。エージェントは、最も重要なメディアストリームがある場合は、それを SDP の最初に配置すべきです (SHOULD)。

特定のメディアストリームの各候補には、candidate 属性があります。セクション 15 では、この属性を構築するための詳細なルールを提供しています。属性には、候補の IP アドレス、ポート、およびトランスポートプロトコルに加えて、ICE が機能するためにピアに通知する必要があるプロパティ（優先順位、ファンデーション、コンポーネント ID）が含まれています。candidate 属性には、診断やその他の機能に役立つ候補に関する情報（タイプと関連するトランスポートアドレス）も含まれています。

エージェント間の STUN 接続チェックは、STUN [RFC5389] で定義されている短期的な資格情報メカニズムを使用して認証されます。このメカニズムは、クライアントとサーバー間のプロトコルメカニズムを通じて交換されるユーザー名とパスワードに依存しています。ICE では、オファー/アンサー交換を使用してそれらを交換します。この資格情報のユーザー名部分は、各エージェントからのユーザー名フラグメントをコロンで区切って連結することによって形成されます。各エージェントは、受信したリクエストのメッセージ整合性を計算するために使用されるパスワードも提供します。ユーザー名フラグメントとパスワードは、それぞれ ice-ufrag 属性と ice-pwd 属性で交換されます。セキュリティを提供するだけでなく、ユーザー名は、チェックの曖昧性解消とメディアストリームへの相関を提供します。動機については、付録 B.4 を参照してください。

エージェントがライト実装である場合、SDP に "a=ice-lite" セッションレベル属性を含めなければなりません (MUST)。エージェントがフル実装である場合、この属性を含めてはなりません (MUST NOT)。

デフォルト候補は、メディアのデフォルト宛先として SDP に追加されます。RTP に基づくストリームの場合、これは、RTP 候補の IP アドレスとポートをそれぞれ c 行と m 行に配置することによって行われます。エージェントが RTCP を利用している場合、RFC 3605 [RFC3605] で定義されている a=rtcp 属性を使用して RTCP 候補をエンコードしなければなりません (MUST)。RTCP が使用されていない場合、エージェントは RFC 3556 [RFC3556] で定義されている b=RS:0 および b=RR:0 を使用してそのことを通知しなければなりません (MUST)。

非 ICE ピアと通信するときにメディアのデフォルト宛先となるトランスポートアドレスも、1 つ以上の a=candidate 行に候補として存在しなければなりません (MUST)。

ICE は、オファーまたはアンサーに、そのエージェントが使用する ICE 拡張を識別する一連のトークンを含めることができるようにすることで、拡張性を提供します。エージェントが ICE 拡張をサポートしている場合、ice-options 属性にその拡張に対して定義されたトークンを含めなければなりません (MUST)。

以下は、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 パケットとメディアパケットの両方を受信する準備をしなければなりません (MUST)。セクション 11.1 で説明されているように、メディアパケットは、オファーまたはアンサーでメディアのデフォルト宛先として表示される前に、候補に送信される場合があります。