1. はじめに
リアルタイム輸送プロトコル (RTP) [RFC3550] が最初に設計された当時、およびその後かなりの期間、RTP セッションのエンドポイントは通常、単一のメディアソースのみを送信していたため、RTP セッションごとに単一の RTP ストリームと同期ソース (SSRC) を使用していました。異なるメディアタイプには、通常、個別の RTP セッションが使用されていました。しかし最近、エンドポイントが単一の RTP セッション内で、個別の RTP 同期ソース (SSRC) 識別子によって区別される複数の RTP ストリームを送信したいというシナリオが多数出現しています。RTP の初期設計でもこのようなシナリオは考慮されていましたが、仕様は一貫してそのようなユースケースを念頭に置いて書かれたものではなかったため、仕様の場所によってはやや不明確な点があります。
本メモは、エンドポイントが複数の SSRC を使用するユースケースにおける動作を明確にするために [RFC3550] を更新します。また、アクティブでない SSRC のタイムアウトに関する問題を解決し、フィードバックメッセージの包含に関する動作を明確にするために [RFC4585] を更新します。
2. 用語
本文書におけるキーワード「MUST（しなければならない）」、「MUST NOT（してはならない）」、「REQUIRED（必須）」、「SHALL（するものとする）」、「SHALL NOT（しないものとする）」、「SHOULD（すべきである）」、「SHOULD NOT（すべきではない）」、「RECOMMENDED（推奨される）」、「NOT RECOMMENDED（推奨されない）」、「MAY（してもよい）」、および「OPTIONAL（任意）」は、RFC 2119 [RFC2119] の記述に従って解釈されるべきものであり、準拠した実装の要件レベルを示します。
3. マルチストリームエンドポイントのユースケース
このセクションでは、単一の RTP セッション内で複数の SSRC を使用して RTP データを送信するエンドポイントの開発を動機付けてきた、いくつかのユースケースについて説明します。
3.1. 複数のキャプチャデバイスを備えたエンドポイント
エンドポイントが単一の RTP セッション内で複数の RTP ストリームを同時に送信する最も直接的な動機の1つは、エンドポイントが複数のキャプチャデバイスを持ち、したがって同じメディアタイプと特性を持つ複数のメディアソースを生成できる場合です。たとえば、CLUE テレプレゼンスフレームワーク [CLUE-FRAME] で説明されているタイプのテレプレゼンスシステムでは、部屋のさまざまなエリアをカバーする複数のカメラやマイクを備えていることが多く、したがって単一の RTP セッション内で各タイプの複数の RTP ストリームを送信します。
3.2. 単一の RTP セッションにおける複数のメディアタイプ
近年の研究により、異なるメディアタイプのメディアソースは常に異なる RTP セッションで送信されるという RTP のこれまでの前提を取り除くために、RTP [MULTI-RTP] とセッション記述プロトコル (SDP) [SDP-BUNDLE] が更新されました。この作業では、使用されるトランスポート層のフロー数を削減するために、単一のエンドポイントの（たとえば）オーディオとビデオの RTP ストリームが代わりに単一の RTP セッションで送信されます。
3.3. マルチストリームミキサー
セッション内でそれ自体が複数の RTP ストリームを生成する中央デバイスが関与する RTP トポロジがいくつか存在します。一例は、セクション 3.1 で説明したようなマルチキャプチャシナリオに対して集中型の合成（コンポジット）を提供するミキサーです。この場合、集中型ノードはマルチキャプチャエンドポイントと非常によく似た動作をし、いくつかの類似した関連するソースを生成します。
3.4. 単一のメディアソースに対する複数の SSRC
セッション内の単一のメディアソースからデータを送信するために複数の SSRC が使用されるケースがいくつかあります。これらには以下が含まれます。
- 階層型またはマルチ記述コーデック: 異なるレイヤーまたは記述が異なる SSRC で送信される場合
- トランスポートの堅牢性メカニズム: RTP 再送 [RFC4588] や前方向誤り訂正 [RFC5109] など
- サイマルキャスト: 同じソースの複数のエンコーディングを異なる品質または解像度で送信する場合