12. Usage with SIP (SIP での使用)
12.1. Latency Guidelines (レイテンシのガイドライン)
ICE は、エンドポイント間で一連の STUN ベースの接続性チェックが行われることを必要とします。これらのチェックは、アンサー側がアンサーを生成したときに開始され、オファー側がアンサーを受信したときに開始されます。これらのチェックは完了までに時間がかかる可能性があるため、オファーとアンサーで使用するメッセージの選択は、知覚されるユーザーレイテンシに影響を与える可能性があります。特に興味深い 2 つのレイテンシの数値があります。これらは、ポストピックアップ遅延（post-pickup delay）とポストダイヤル遅延（post-dial delay）です。ポストピックアップ遅延とは、ユーザーが「電話に出る」ときから、ユーザーが発した音声が発信者に届くまでの時間を指します。ポストダイヤル遅延とは、ユーザーがユーザーの宛先アドレスを入力してから、着信側の電話が正常に鳴り始めた結果としてリングバックが開始されるまでの時間を指します。
オファーが初期 INVITE に存在するケースと、レスポンスに存在するケースの 2 つのケースを考慮することができます。
12.1.1. Offer in INVITE (INVITE 内のオファー)
ポストダイヤル遅延を減らすために、発信者は実際の初期 INVITE を送信する前に候補の収集を開始することが RECOMMENDED です。これは、キーパッドでの操作や電話のオフフックなど、通話が保留中であるというユーザーインターフェイスの手がかりによって開始できます。
オファーが INVITE リクエストで受信された場合、アンサー側はオファーの受信時に候補の収集を開始し (SHOULD)、そのプロセスが完了したら暫定応答でアンサーを生成する必要があります。ICE は、SDP を含む暫定応答が確実に送信されることを要求します。これは、既存の暫定応答確認（PRACK）メカニズム [RFC3262] を介して、または ICE に固有の最適化を介して行うことができます。この最適化により、1 つ以上のメディアストリームの ICE 処理を開始する SDP アンサーを含む暫定応答は、RFC 3262 なしで確実に送信できます。これを行うには、エージェントは RFC 3262 で説明されている指数バックオフタイマーを使用して暫定応答を再送します。再送は、その SDP でシグナリングされたメディアストリームの 1 つに対する STUN Binding リクエストを受信したとき（Binding リクエストの受信は、オファー側がアンサーを受信したことを示すため）、または 2xx 応答でアンサーを送信したときに停止しなければなりません (MUST)。ピアエージェントが lite の場合、STUN Binding リクエストは発生しません。そのような場合、エージェントは 18x を 4 回送信した後、再送を停止しなければなりません (MUST)（ICE は、ピアが 18x を受信しなくても実際には機能しますが、経験上、それを送信することはミドルボックスとファイアウォールの通過にとって重要であることが示されています）。最後の再送の前に Binding リクエストが受信されない場合、エージェントはセッションが終了したとは見なしません。暫定応答が確実に配信されるという事実にもかかわらず、エージェントが更新されたオファーまたはアンサーを送信できるタイミングのルールは、RFC 3262 で指定されたルールから変更されません。具体的には、INVITE にオファーが含まれていた場合、同じアンサーがすべての 1xx および INVITE に対する 2xx 応答に表示されます。その 2xx が送信された後にのみ、更新されたオファー/アンサー交換を行うことができます。両方のエージェントが PRACK をサポートしている場合、この最適化は使用すべきではありません (SHOULD NOT)。この最適化は、ICE 処理を開始するアンサーを運ぶ暫定応答に非常に固有であることに注意してください。これは 1xx の信頼性のための一般的な手法ではありません。
あるいは、エージェントは 200 OK までアンサーの送信を遅らせることができます (MAY)。ただし、これはユーザーエクスペリエンスの低下を招くため、NOT RECOMMENDED です。
アンサーが送信されると、エージェントは接続性チェックを開始すべきです (SHOULD)。メディアストリームの各コンポーネントの候補ペアが有効リストに入ると、アンサー側はそのメディアストリームでのメディアの送信を開始できます。
ただし、この時点より前に、発信者に向けて送信する必要があるメディア（SIP アーリーメディア [RFC3960] など）は送信してはなりません (MUST NOT)。このため、実装は、各メディアストリームの各コンポーネントの候補が有効リストに入るまで、着信側への呼び出しを遅らせるべきです (SHOULD)。PSTN ゲートウェイの場合、これは、PSTN へのセットアップメッセージがこの時点まで遅延することを意味します。これを行うと、ポストダイヤル遅延が増加しますが、「ゴーストリング」を排除する効果があります。ゴーストリングとは、着信側が電話の呼び出し音を聞いて電話に出たが、何も聞こえず、相手にも聞こえない場合のことです。この手法は、ローカライズされた決定であるため、前提条件 [RFC3312] のサポートや使用を必要とせずに機能します。また、メディアのパケットが 1 つもクリップされないことが保証されるため、ポストピックアップ遅延がゼロになるという利点もあります。エージェントがこのようにローカル呼び出しを遅らせることを選択した場合、呼び出しが開始されたら 180 応答を生成すべきです (SHOULD)。
12.1.2. Offer in Response (レスポンス内のオファー)
オファーが INVITE にあり、アンサーが暫定および/または 200 OK 応答にある用途に加えて、ICE はオファーが応答に表示されるケースでも機能します。サードパーティのコール制御 [RFC3725] で一般的なこのようなケースでは、ICE エージェントは、信頼できる暫定応答（RFC 3262 を利用しなければなりません (MUST)）でオファーを生成し (SHOULD)、INVITE の受信時にユーザーに警告しないようにすべきです。アンサーは PRACK で到着します。これにより、呼び出しの前に ICE 処理を行うことができるため、ポストピックアップ遅延は発生しませんが、コールセットアップ遅延が増加するという犠牲を伴います。ICE が完了すると、着信側はユーザーに警告し、応答したときに 200 OK を生成できます。オファー/アンサー交換が完了しているため、200 OK には SDP が含まれません。
あるいは、エージェントは代わりに 2xx にオファーを配置することもできます (MAY)（その場合、アンサーは ACK で来ます）。これが発生すると、着信側は INVITE の受信時にユーザーに警告し、ICE 交換はユーザーが応答した後にのみ行われます。これには、コールセットアップ遅延を減らす効果がありますが、かなりのポストピックアップ遅延とメディアクリッピングを引き起こす可能性があります。
12.2. SIP Option Tags and Media Feature Tags (SIP オプションタグとメディア機能タグ)
[RFC5768] は、ICE で使用するための SIP オプションタグとメディア機能タグを指定しています。SIP を使用する ICE 実装は、この仕様をサポートすべきです (SHOULD)。この仕様は、登録で機能タグを使用して、シグナリング仲介者を介した相互運用性を促進します。
12.3. Interactions with Forking (フォーキングとの相互作用)
ICE はフォーキングと非常によく相互作用します。実際、ICE はフォーキングに関連するいくつかの問題を修正します。ICE がない場合、コールがフォークし、発信者が複数の着信メディアストリームを受信すると、どのメディアストリームがどの着信側に対応するかを判断できません。
ICE を使用すると、この問題は解決されます。メディアの送信前に行われる接続性チェックには、ユーザー名フラグメントが含まれており、これらは特定の着信側に関連付けられています。接続性チェックと同じ候補ペアに到着する後続のメディアパケットは、その同じ着信側に関連付けられます。したがって、発信者は、アンサーを受信している限り、この相関を実行できます。
12.4. Interactions with Preconditions (前提条件との相互作用)
RFC 3312 [RFC3312] および RFC 4032 [RFC4032] で定義されている Quality of Service（QoS）前提条件は、オファー/アンサーでメディアのデフォルトターゲットとしてリストされているトランスポートアドレスにのみ適用されます。
ICE がメディアを受信するトランスポートアドレスを変更した場合、この変更は、メディアのデフォルトの宛先を ICE の選択と一致するように変更する更新されたオファーに反映されます。そのため、他の再 INVITE と同様に見え、RFC 3312 および 4032 で完全に処理されます。これらの RFC は、メディアの宛先が「バックグラウンド」で発生している ICE ネゴシエーションのために変更されているという事実に関係なく適用されます。
実際、エージェントは、チェックが完了し、メディアに使用される候補ペアが選択されるまで、QoS 前提条件が満たされたことを示すべきではありません (SHOULD NOT)。
ICE は、接続性前提条件 [SDP-PRECON] とも（意図的な）相互作用を持ちます。それらの相互作用はそこで説明されています。セクション 12.1 で説明されている手順は、[SDP-PRECON] の明示的な前提条件によって提供される機能よりも機能は少ないものの、独自のタイプの「前提条件」を記述していることに注意してください。
12.5. Interactions with Third Party Call Control (サードパーティコール制御との相互作用)
ICE は、[RFC3725] で説明されているフロー I、III、および IV で機能します。フロー I は、コントローラーが ICE をサポートまたは認識していなくても機能します。フロー IV は、コントローラーが ICE 属性を変更せずに渡す限り機能します。フロー II は、ICE と根本的に互換性がありません。各エージェントは自分自身をアンサー側であると信じ、再 INVITE を生成することはありません。
RFC 3725 のセクション 7 で説明されている継続的な操作のフローには、サポートするために ICE 実装の追加の動作が必要です。特に、エージェントがオファーを含まないダイアログ中の再 INVITE を受信した場合、各メディアストリームに対して ICE を再開し、新しい候補を収集するプロセスを経なければなりません (MUST)。さらに、その候補リストには、現在メディアに使用されているものが含まれるべきです (SHOULD)。