3. マルチストリームエンドポイントのユースケース

この節では、単一の RTP セッション内で複数の SSRC を使用して RTP データを送信するエンドポイントの開発を動機付けてきた、いくつかのユースケースについて論じる。

3.1. 複数のキャプチャデバイスを持つエンドポイント

エンドポイントが単一の RTP セッション内で複数の RTP ストリームを同時に送信する最もわかりやすい動機は、エンドポイントが複数のキャプチャデバイスを持ち、したがって同じメディアタイプと特性を持つ複数のメディアソースを生成できる場合である。例えば、CLUE テレプレゼンスフレームワーク [CLUE-FRAME] で記述されている種類のテレプレゼンスシステムは、部屋のさまざまな領域をカバーする複数のカメラやマイクを持つことが多く、したがって単一の RTP セッション内で各タイプの複数の RTP ストリームを送信する。

3.2. 単一の RTP セッションにおける複数のメディアタイプ

最近の取り組みにより、異なるメディアタイプのメディアソースは常に異なる RTP セッションで送信されるという RTP の従来の前提を取り除くために、RTP [MULTI-RTP] とセッション記述プロトコル (SDP) [SDP-BUNDLE] が更新された。この取り組みでは、使用するトランスポート層フローの数を削減するために、単一のエンドポイントの（例えば）音声と映像の RTP ストリームが、代わりに単一の RTP セッションで送信される。

3.3. 複数のストリームミキサー

セッション内でそれ自体が複数の RTP ストリームを生成する中央デバイスが関与しうる RTP トポロジがいくつか存在する。一例は、セクション 3.1 で記述したようなマルチキャプチャシナリオに対して集中型のコンポジットを提供するミキサーである。この場合、中央ノードはマルチキャプチャエンドポイントと非常によく似た動作をし、いくつかの類似した関連するソースを生成する。

より複雑な例は、[RFC7667] のセクション 3.7 で記述されている選択的転送ミドルボックスである。これは、複数のエンドポイントから RTP ストリームを受信し、その後、接続されている他のエンドポイントに向けて、一部の RTP ストリームの変更版を選択的に転送するミドルボックスである。接続された各エンドポイントについて、ミドルボックスに接続された他のすべてのソースに対応する別個のメディアソースが、元のストリームから「投影」されてセッション内に現れるが、任意の時点でその多くは非アクティブに見える可能性がある（したがって、RTP では送信者ではなく受信者である）。この種のデバイスは、RTP トランスレータというよりも RTP ミキサーに近い。すなわち、混合されたストリームに関する RTCP 報告を終端し、SSRC、タイムスタンプ、シーケンス番号、および RTP ペイロードの内容を書き換えることができ、パケット損失を発生させることなく任意にソースをオン/オフできる。投影された各ストリームは通常、元の RTCP ソース記述 (SDES) 情報を保持する。

3.4. 単一のメディアソースに対する複数の SSRC

また、単一の RTP セッション内で単一のメディアソースからデータを送信するために複数の SSRC を使用できるケースもいくつかある。これには、メディアデータに 1 つの SSRC を、修復データに別の SSRC を使用することを必要とする、RTP 再送ペイロード形式 [RFC4588] のようなトランスポート堅牢化ツールが含まれるが、これらに限定されない。同様に、例えば H.264 スケーラブルビデオ符号化 (SVC) [RFC6190] のようないくつかの階層型メディア符号化方式は、単一の RTP セッション内で各レイヤーを異なる SSRC を使用して送信する構成で使用できる。