RFC 3550 - 2. RTP の利用シナリオ
2. RTP の利用シナリオ (RTP Use Scenarios)
以下の各節では RTP の利用に関するいくつかの側面を記述する。これらの例は、RTP を用いるアプリケーションの基本動作を説明するために選ばれたものであって、RTP の利用範囲を限定するものではない。これらの例では、RTP は IP および UDP 上で運ばれ、関連 RFC 3551 で規定された音声・映像プロファイルの慣習に従う。
2.1 単純なマルチキャスト音声会議 (Simple Multicast Audio Conference)
IETF のワーキンググループが、インターネットの IP マルチキャストサービスを用いた音声通信で最新のプロトコル文書について議論する。何らかの割り当てメカニズムによって、ワーキンググループの議長はマルチキャストグループアドレスと一対のポートを取得する。一方のポートは音声データ用、もう一方は制御（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 パケットで同じ識別（正規）名を用いるべきである。
この分離の一つの動機は、会議の一部の参加者が望めば一方のメディアのみを受信できるようにすることである。さらなる説明はセクション 5.2 にある。分離されているにもかかわらず、送信元の音声と映像の同期再生は、両セッションの RTCP パケットに含まれるタイミング情報を用いて達成できる。
2.3 ミキサとトランスレータ (Mixers and Translators)
これまで、すべてのサイトが同じ形式でメディアデータを受信したいと仮定してきた。しかし、これが常に適切とは限らない。ある地域の参加者が低速リンクで、高速ネットワークにアクセスしている大多数の参加者と接続されている場合を考えよう。全員に帯域幅の狭い低品質の音声符号化を強いる代わりに、低速帯域地域の近くにミキサと呼ばれる RTP レベルの中継器を配置できる。このミキサは、入力された音声パケットを再同期して送信側が生成した一定の 20 ミリ秒間隔を再構成し、これらの再構成された音声ストリームを 1 つのストリームにミキシングし、音声符号化をより低帯域のものへ変換し、その低帯域パケットストリームを低速リンク越しに転送する。これらのパケットは単一の受信者へユニキャストされても、複数の受信者へ異なるアドレスでマルチキャストされてもよい。RTP ヘッダには、ミキサがミキシングされたパケットに寄与した送信元を識別する手段が含まれ、受信側で正しい発話者表示を提供できる。
音声会議の一部の参加者は広帯域リンクで接続されていても、IP マルチキャスト経由で直接到達できない場合がある。たとえば、いかなる IP パケットも通さないアプリケーション層ファイアウォールの内側にある場合である。これらのサイトではミキシングは不要な場合があり、その際にはトランスレータと呼ばれる別種の RTP レベル中継器を用いてよい。2 つのトランスレータがファイアウォールの両側に設置され、外側のものは受信したすべてのマルチキャストパケットをセキュアな接続でファイアウォール内側のトランスレータへ流し込む。ファイアウォール内側のトランスレータは、それらを再びマルチキャストパケットとして、サイト内ネットワークに限定されたマルチキャストグループへ送信する。
ミキサとトランスレータはさまざまな目的のために設計できる。例として、別々の映像ストリームにある個々の人物の画像を縮小し、1 つの映像ストリームに合成してグループの情景を模倣する映像ミキサがある。翻訳の他の例には、IP/UDP のみを話すホスト群と ST-II しか理解できないホスト群の接続、あるいは再同期やミキシングなしでの個々の送信元からの映像ストリームのパケットごとの符号化変換などがある。ミキサとトランスレータの動作の詳細はセクション 7 にある。
2.4 階層的符号化 (Layered Encodings)
マルチメディアアプリケーションは、受信側の能力に合わせ、あるいはネットワーク輻輳に適応するため、伝送レートを調整できなければならない。多くの実装は、レート適応の責任を送信元に置く。これはマルチキャスト伝送ではうまく働かない。なぜなら、性質の異なる受信者の間で帯域幅要求が衝突するからである。結果としてしばしば最小公分母シナリオとなり、ネットワークメッシュ内の最小のパイプが、全体のライブマルチメディア「放送」の品質と忠実度を決定づける。
代わりに、階層的符号化と階層的伝送システムを組み合わせることで、レート適応の責任を受信側に置くことができる。IP マルチキャスト上の RTP の文脈では、送信元は、階層的に表現された信号の進行的な層を、それぞれ独自のマルチキャストグループで運ばれる複数の RTP セッションにまたがってストライプ化（帯域分割）できる。そうすれば受信者は、ネットワークの異質性に適応し、マルチキャストグループの適切な部分集合のみに参加することで、受信帯域幅を制御できる。
RTP を階層的符号化とともに用いることの詳細は、セクション 6.3.9、8.3、および 11 にある。