9. RTSP に関する考慮 (RTSP Considerations)
リアルタイムストリーミングプロトコル (RTSP), RFC 2326 [7], は, リアルタイム特性を持つデータの配送制御のためのアプリケーションレベルプロトコルである. 本節では再送を用いる RTP セッションを制御する際の論点を扱う.
9.1. SSRC 多重化での RTSP 制御
SSRC 多重化の場合, "m" 行にはオリジナルと再送の両方のペイロード型が含まれ, 単一の RTSP "control" 属性を持つ. 受信者は "m" 行を用いてメディアセッション全体の SETUP および TEARDOWN を要求する. Transport ヘッダに含まれる RTP プロファイルは MUST で AVPF プロファイルまたは拡張フィードバックを許す他の適切なプロファイルでなければならない. SETUP 応答の Transport ヘッダに SSRC 値が含まれる場合, MUST でオリジナルストリームのものでなければならない.
セッションのオリジナルメディアストリームの送信を制御するため, 受信者は従来どおり送信者に対してセッションの PLAY および PAUSE 要求を送る. PLAY 応答で RTP 固有パラメータを設定するために用いられる RTP-info ヘッダは MUST でオリジナルストリームの RTP 情報に従って設定しなければならない.
受信者がオリジナルストリームの受信を開始すると, 追加の RTSP シグナリングなしに RTCP NACK により再送を要求できる.
9.2. セッション多重化での RTSP 制御
セッション多重化の場合, 各 SDP "m" 行に RTSP "control" 属性がある. したがって再送を用いる場合, オリジナルセッションと再送の両方に独自の "control" 属性がある. 受信者は 8 節で指定されるとおり FID セマンティクスを通じてオリジナルセッションと再送セッションを関連付けられる.
オリジナルと再送ストリームは, それぞれのメディア "control" 属性を通じて別々にセットアップおよびティアダウンされる. Transport ヘッダに含まれる RTP プロファイルは MUST で, オリジナルおよび再送セッションの両方について AVPF プロファイルまたは拡張フィードバックを許す他の適切なプロファイルでなければならない.
RTSP プレゼンテーションは SHOULD で集約制御 (aggregate control) を支援し, SHOULD でセッションレベルの RTSP URL を含めるべきである. 受信者は SHOULD で, オリジナルセッションと関連する再送セッションに対して集約制御を用いるべきである. そうでないと, オリジナルと再送セッションで異なる 2 つの 'session-id' 値が必要になり, 送信者がそれらを関連付けられなくなる.
セッションレベルの "control" 属性は従来どおりオリジナルストリームの再生制御に用いられる. 受信者がオリジナルストリームの受信を開始すると, 追加の RTSP シグナリングなしに RTCP により再送を要求できる.
9.3. 再送ストリームの RTSP 制御
再送の性質上, 再送パケットの送信は SHOULD NOT で RTSP の PLAY および PAUSE 要求により制御すべきではない. PLAY および PAUSE 要求は SHOULD NOT で再送ストリームに影響すべきではない. 再送パケットは状態に関わらず, オリジナル RTCP ストリームでの受信者要求に応じて送られる.
9.4. キャッシュ制御
再送ストリームは SHOULD NOT でキャッシュすべきではない.
セッション多重化の場合, 再送ストリームに対して "Cache-Control" ヘッダは SHOULD で "no-cache" に設定すべきである.
SSRC 多重化の場合, SDP に "m" 行が 1 つしかないため, RTSP は再送ストリームに対して独立したキャッシュ指定ができない. したがって実装者は, SSRC 多重化セッションをキャッシュするかどうかを決める際にこの事実を考慮すべきである.