9 Connections (接続)

RTSP リクエストは複数の異なる方法で伝送できます:

複数のリクエスト-レスポンストランザクションに用いる持続的トランスポート接続;
リクエスト/レスポンストランザクションごとに 1 接続;
非接続モード。

トランスポート接続の種類は RTSP URI (セクション 3.2) で定義されます。スキーム "rtsp" では持続接続を仮定し, スキーム "rtspu" では接続を確立せずに RTSP リクエストを送ることを求めます。

HTTP とは異なり, RTSP はメディアサーバーがメディアクライアントへリクエストを送ることを許します。ただしこれは持続接続でのみサポートされます。そうでなければメディアサーバーはクライアントに到達する確実な手段を持ちません。また, サーバーからクライアントへのリクエストがファイアウォールを越えやすいのもこの方法だけです。

9.1 Pipelining (パイプライン化)

持続接続または非接続モードをサポートするクライアントは, リクエストを "パイプライン化" しても MAY します (各レスポンスを待たずに複数リクエストを送る)。サーバーは MUST, 受信した順序と同じ順序でそれらのリクエストに対するレスポンスを送ります。

9.2 Reliability and Acknowledgements (信頼性と確認)

マルチキャストグループへ送られない限り, リクエストは受信者によって確認されます。確認がなければ, 送信者は 1 往復時間 (RTT) のタイムアウト後に同一メッセージを再送してもよいでしょう。往復時間は TCP (RFC 1123) [18] と同様に推定し, 初期往復値は 500 ms です。実装は MAY, 最後の RTT 測定を将来の接続の初期値としてキャッシュします。

RTSP を運ぶのに信頼できるトランスポートプロトコルを用いる場合, リクエストは MUST NOT 再送されます。RTSP アプリケーションは MUST, 信頼性を下位トランスポートに委ねます。

下位の信頼トランスポート (TCP など) と RTSP アプリケーションの両方がリクエストを再送すると, パケット損失ごとに再送が二重に起こり得ます。受信者は通常アプリケーション層の再送を活用できません。最初の試行が受信者に届く前に,

トランスポートスタックがアプリケーション層の再送を上に届けないためです。輻輳が原因の損失では, 層をまたいだ複数再送が輻輳を悪化させます。

RTT の小さい LAN で RTSP を使う場合, T/TCP (RFC 1644) [22] などで用いる初期 TCP 往復推定の最適化手順が有益になり得ます。

Timestamp ヘッダー (セクション 12.38) は再送の曖昧さ問題 [23, p. 301] を避け, Karn のアルゴリズムの必要性をなくします。

各リクエストは CSeq ヘッダー (セクション 12.17) にシーケンス番号を運び, 区別されるリクエストを送るたびに 1 増やします。確認がないためにリクエストを繰り返す場合, リクエストは MUST 元のシーケンス番号を運びます (増分しません)。

RTSP を実装するシステムは MUST TCP 上の RTSP をサポートし, MAY UDP をサポートします。RTSP サーバーのデフォルトポートは UDP と TCP の両方で 554 です。

同一制御エンドポイント宛の複数の RTSP パケットは, 単一の下位層 PDU にまとめるか TCP ストリームにカプセル化してもよいでしょう。RTSP データは MAY RTP および RTCP パケットとインターリーブされます。HTTP とは異なり, メッセージにペイロードがあるときは常に RTSP メッセージは MUST Content-Length ヘッダーを含みます。そうでなければ, RTSP パケットは最後のメッセージヘッダー直後の空行で終端します。