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

11. Media Handling (メディア処理)

11.1. Sending Media (メディアの送信)​

メディアを送信する手順は、完全な実装と Lite 実装で異なります。

11.1.1. Procedures for Full Implementations (完全な実装の手順)​

エージェントは常に、選択された候補ペアと呼ばれる候補ペアを使用してメディアを送信します。エージェントは、選択されたペアのリモート候補にメディアを送信し（パケットの宛先アドレスとポートをそのリモート候補と等しく設定）、選択されたペアのローカル候補から送信します。ローカル候補がサーバー反射またはピア反射の場合、メディアはベースから発信されます。リレー候補から送信されるメディアは、[RFC5766] で定義された手順を使用して、ベースからその TURN サーバーを介して送信されます。

ローカル候補がリレー候補である場合、エージェントは TURN サーバー上にリモート候補に向けたチャネルを作成することが推奨されます (RECOMMENDED)。これは、[RFC5766] のセクション 11 で定義されているチャネル作成の手順を使用して行われます。

メディアストリームのコンポーネントの選択されたペアは次のとおりです。

  • そのメディアストリームのチェックリストの状態が Running であり、ICE 再起動のためにそのコンポーネントの以前の選択されたペアがない場合は空

  • そのメディアストリームのチェックリストの状態が Running であり、ICE 再起動のためにそのコンポーネントの以前の選択されたペアがあった場合、メディアストリームのコンポーネントの以前の選択されたペアと等しい

  • チェックリストの状態が Completed の場合、有効リスト内のそのコンポーネントの最も優先度の高い指名されたペアと等しい

メディアストリームの少なくとも 1 つのコンポーネントの選択されたペアが空の場合、エージェントはそのメディアストリームのどのコンポーネントのメディアも送信してはなりません (MUST NOT)。メディアストリームの各コンポーネントの選択されたペアに値がある場合、エージェントはそのメディアストリームのすべてのコンポーネントのメディアを送信してもよいです (MAY)。

メディアストリームのコンポーネントの選択されたペアは、最新のオファー/アンサー交換からのその同じコンポーネントのデフォルトのペアと等しくない場合があることに注意してください。これが発生した場合、デフォルトのペアではなく、選択されたペアがメディアに使用されます。ICE が最初に完了したとき、選択されたペアがデフォルトのペアと一致しない場合、制御エージェントはこの不一致を修正するために更新されたオファー/アンサー交換を送信します。ただし、その更新されたオファーが到着するまでは、一致しません。さらに、非常にまれなケースでは、更新されたオファー/アンサーのデフォルトの候補が一致しません。

11.1.2. Procedures for Lite Implementations (Lite 実装の手順)​

Lite 実装は、そのメディアストリームの各コンポーネントの候補ペアを含む Valid リストを持つまで、メディアを送信してはなりません (MUST NOT)。それが発生すると、エージェントはメディアパケットの送信を開始してもよいです (MAY)。これを行うために、ペアのリモート候補にメディアを送信し（パケットの宛先アドレスとポートをそのリモート候補と等しく設定）、ローカル候補から送信します。

11.1.3. Procedures for All Implementations (すべての実装の手順)​

ICE は、ジッターバッファ適応メカニズムとの相互作用を持ちます。RTP ストリームは 1 つの候補を使用して開始し、別の候補に切り替えることができますが、ICE ではこれはめったに発生しません。新しい候補により、RTP パケットがネットワークを通る別のパス（異なる遅延特性を持つパス）を通過する可能性があります。以下で説明するように、エージェントは、メディアパケットの送信元または宛先アドレスに変更がある場合、ジッターバッファを再調整することが推奨されます。さらに、多くのオーディオコーデックは、ジッターバッファ適応の目的で、トークスパートの開始を通知するためにマーカービットを使用します。そのようなコーデックの場合、エージェントがメディアの送信をある候補ペアから別の候補ペアに切り替えるときに、送信者がマーカービット [RFC3550] を設定することが推奨されます (RECOMMENDED)。

11.2. Receiving Media (メディアの受信)​

ICE 実装は、最新のオファー/アンサー交換でそのコンポーネントに提供された候補の各コンポーネントでメディアを受信する準備ができていなければなりません (MUST)（RTP の場合、両方の候補が提供された場合、これには RTP と RTCP の両方が含まれます）。

エージェントが特定のメディアストリームの新しい送信元または宛先 IP アドレスを持つ RTP パケットを受信した場合、エージェントがジッターバッファを再調整することが推奨されます (RECOMMENDED)。

RFC 3550 [RFC3550] は、同期ソース (SSRC) の衝突とループを検出するためのアルゴリズムをセクション 8.2 で説明しています。これらのアルゴリズムは、部分的には、同じ SSRC を持つ異なる送信元トランスポートアドレスを見ることに基づいています。ただし、ICE が使用される場合、メディアストリームが候補間で切り替わるときに、このような変更が発生することがあります。エージェントは、メディア送信に先行する STUN 交換の結果として、メディアストリームが同じピアからのものであると判断できます。したがって、送信元トランスポートアドレスに変更があっても、メディアパケットが同じピアエージェントからのものである場合、これは SSRC 衝突として扱われるべきではありません (SHOULD NOT)。

に最終更新