2. RTP使用シナリオ (RTP Use Scenarios)

以下のセクションでは、RTPの使用に関するいくつかの側面について説明します。これらの例は、RTPを使用するアプリケーションの基本的な動作を説明するために選択されたものであり、RTPの使用を制限するものではありません。これらの例では、RTPはIPおよびUDP上で伝送され、付属のRFC 3551で規定されている音声およびビデオのプロファイルによって確立された規則に従います。

2.1 簡単なマルチキャスト音声会議 (Simple Multicast Audio Conference)

IETFのワーキンググループが最新のプロトコル文書について議論するために、インターネットのIPマルチキャストサービスを使用して音声通信を行います。何らかの割り当てメカニズムを通じて、ワーキンググループの議長はマルチキャストグループアドレスとポートのペアを取得します。1つのポートは音声データに使用され、もう1つは制御 (RTCP) パケットに使用されます。このアドレスとポート情報は、意図された参加者に配布されます。プライバシーが必要な場合、データおよび制御パケットはセクション9.1で規定されているように暗号化される場合があり、その場合、暗号化キーも生成して配布する必要があります。これらの割り当ておよび配布メカニズムの正確な詳細は、RTPの範囲外です。

各会議参加者が使用する音声会議アプリケーションは、例えば20ミリ秒の持続時間の小さなチャンクで音声データを送信します。各音声データのチャンクの前にRTPヘッダーが付けられます。RTPヘッダーとデータは、UDPパケットに含まれます。RTPヘッダーは、各パケットに含まれる音声エンコーディングのタイプ (PCM、ADPCM、LPCなど) を示すため、送信者は会議中にエンコーディングを変更できます。例えば、低帯域幅リンクを介して接続されている新しい参加者に対応したり、ネットワーク輻輳の兆候に対応したりするためです。

インターネットは、他のパケットネットワークと同様に、時折パケットを失ったり並べ替えたり、可変時間だけ遅延させたりします。これらの障害に対処するために、RTPヘッダーにはタイミング情報とシーケンス番号が含まれており、受信者はソースによって生成されたタイミングを再構築できます。この例では、音声のチャンクが20ミリ秒ごとにスピーカーから連続して再生されます。このタイミング再構築は、会議内の各RTPパケットソースに対して個別に実行されます。シーケンス番号は、受信者がどれだけのパケットが失われているかを推定するためにも使用できます。

ワーキンググループのメンバーは会議中に参加および退出するため、誰がいつ参加しているか、および音声データをどの程度うまく受信しているかを知ることは有用です。その目的のために、会議内の音声アプリケーションの各インスタンスは、RTCP (制御) ポート上で受信レポートとそのユーザーの名前を定期的にマルチキャストします。受信レポートは、現在の話者がどの程度うまく受信されているかを示し、適応型エンコーディングを制御するために使用される場合があります。ユーザー名に加えて、他の識別情報も制御帯域幅の制限の対象として含まれる場合があります。サイトは、会議を離れるときにRTCP BYEパケット (セクション6.6) を送信します。

2.2 音声およびビデオ会議 (Audio and Video Conference)

会議で音声とビデオの両方のメディアが使用される場合、それらは別個のRTPセッションとして送信されます。つまり、各メディアに対して、2つの異なるUDPポートペアおよび/またはマルチキャストアドレスを使用して、個別のRTPおよびRTCPパケットが送信されます。RTPレベルでは、音声セッションとビデオセッションの間に直接的な結合はありませんが、両方のセッションに参加しているユーザーは、セッションを関連付けることができるように、両方のRTCPパケットで同じ識別名 (正規名) を使用する必要があります。

この分離の動機の1つは、会議の一部の参加者が希望する場合に1つのメディアのみを受信できるようにすることです。さらなる説明はセクション5.2に記載されています。この分離にもかかわらず、両方のセッションのRTCPパケットで伝送されるタイミング情報を使用して、ソースの音声とビデオの同期再生を実現できます。

2.3 ミキサーとトランスレータ (Mixers and Translators)

これまで、すべてのサイトが同じ形式でメディアデータを受信したいと仮定してきました。しかし、これが常に適切であるとは限りません。ある地域の参加者が低速リンクを介して、高速ネットワークアクセスを享受している大多数の会議参加者に接続されている場合を考えます。全員に低帯域幅で品質の低い音声エンコーディングを使用させる代わりに、ミキサーと呼ばれるRTPレベルのリレーを低帯域幅エリアの近くに配置できます。このミキサーは、送信者によって生成された一定の20ミリ秒間隔を再構築するために着信音声パケットを再同期し、これらの再構築された音声ストリームを単一のストリームにミックスし、音声エンコーディングを低帯域幅のものに変換し、低速リンクを介して低帯域幅パケットストリームを転送します。これらのパケットは、単一の受信者にユニキャストされるか、複数の受信者に異なるアドレスでマルチキャストされる場合があります。RTPヘッダーには、ミキサーがミックスされたパケットに貢献したソースを識別する手段が含まれているため、受信者で正しい話者表示を提供できます。

音声会議の意図された参加者の一部は、高帯域幅リンクで接続されている場合がありますが、IPマルチキャスト経由で直接到達できない場合があります。例えば、IPパケットを一切通過させないアプリケーションレベルのファイアウォールの背後にある場合があります。これらのサイトでは、ミキシングが不要な場合があり、その場合、トランスレータと呼ばれる別のタイプのRTPレベルのリレーを使用できます。2つのトランスレータがインストールされます。1つはファイアウォールの外側に、もう1つは内側にあり、外側のトランスレータは受信したすべてのマルチキャストパケットをファイアウォール内部のトランスレータへの安全な接続を通じてファネルします。ファイアウォール内部のトランスレータは、それらを再びマルチキャストパケットとして、サイトの内部ネットワークに制限されたマルチキャストグループに送信します。

ミキサーとトランスレータは、さまざまな目的のために設計される場合があります。例としては、個別のビデオストリーム内の個人の画像をスケーリングし、グループシーンをシミュレートするために1つのビデオストリームに合成するビデオミキサーがあります。変換の他の例には、IP/UDPのみを話すホストのグループをST-IIのみを理解するホストのグループに接続すること、または再同期やミキシングなしに個々のソースからのビデオストリームのパケットごとのエンコーディング変換が含まれます。ミキサーとトランスレータの動作の詳細はセクション7に記載されています。

2.4 階層化エンコーディング (Layered Encodings)

マルチメディアアプリケーションは、受信者の容量に一致するように、またはネットワーク輻輳に適応するために、送信レートを調整できる必要があります。多くの実装では、レート適応性の責任をソース側に置きます。これは、異種受信者の矛盾する帯域幅要件のため、マルチキャスト送信ではうまく機能しません。結果は、多くの場合、最小公倍数のシナリオであり、ネットワークメッシュ内の最小のパイプが、ライブマルチメディア「ブロードキャスト」全体の品質と忠実度を決定します。

代わりに、階層化エンコーディングと階層化伝送システムを組み合わせることにより、レート適応の責任を受信者側に置くことができます。IPマルチキャスト上のRTPのコンテキストでは、ソースは階層的に表現された信号の進行的な層を、それぞれ独自のマルチキャストグループで伝送される複数のRTPセッションにわたってストライプ化できます。受信者は、適切なマルチキャストグループのサブセットのみに参加することにより、ネットワークの異質性に適応し、受信帯域幅を制御できます。

階層化エンコーディングでのRTPの使用の詳細は、セクション6.3.9、8.3、および11に記載されています。

---