4 RTSP Message (RTSP メッセージ)

RTSP はテキストベースのプロトコルで, UTF-8 エンコーディングの ISO 10646 文字セット (RFC 2279 [21]) を用います。行は CRLF で終端しますが, 受信側は CR および LF 単独も行終端として解釈できるようにしておくべきです。

テキストベースのプロトコルは, オプションパラメータを自己記述的に追加しやすくします。パラメータ数とコマンド頻度が低いため, 処理効率は問題になりません。注意深く設計されれば, テキストベースのプロトコルは Tcl, Visual Basic, Perl などのスクリプト言語での研究プロトタイプの実装も容易にします。

10646 文字セットは厄介な文字セット切替を避けますが, US-ASCII を用いている限りアプリケーションからは見えません。これは RTCP にも用いられるエンコーディングです。ISO 8859-1 は上位オクテットがゼロの Unicode に直接写像されます。最上位ビットがセットされた ISO 8859-1 文字は 1100001x 10xxxxxx として表されます (RFC 2279 [21] 参照)。

RTSP メッセージは, 8 ビットクリーンな任意の下位層トランスポートプロトコル上で運ばれてもよいでしょう。

リクエストにはメソッド, メソッドが作用する対象, メソッドをさらに記述するパラメータが含まれます。特に記載がない限り, メソッドはべき等です。またメソッドは, メディアサーバー側で状態維持をほとんどまたはまったく必要としないように設計されています。

4.1 Message Types (メッセージ種別)

[H4.1] を参照

4.2 Message Headers (メッセージヘッダー)

[H4.2] を参照

4.3 Message Body (メッセージボディ)

[H4.3] を参照

4.4 Message Length (メッセージ長)

メッセージにメッセージボディが含まれる場合, そのボディの長さは次のいずれかによって決まります (優先順):

メッセージボディを含んではならない (MUST NOT) 任意のレスポンスメッセージ (1xx, 204, 304 レスポンスなど) は, メッセージに存在する entity-header フィールドに関わらず, 常にヘッダーフィールド後の最初の空行で終端します (注: 空行は CRLF のみで構成されます)。
Content-Length ヘッダーフィールド (セクション 12.14) がある場合, そのバイト値が message-body の長さを表します。このヘッダーフィールドがない場合, ゼロを仮定します。
サーバーが接続を閉じること。(接続を閉じることでリクエストボディの終端を示すことはできません。そうするとサーバーがレスポンスを返す余地がなくなります。)

RTSP は (現時点では) HTTP/1.1 の "chunked" 転送コーディング ([H3.6] 参照) をサポートせず, Content-Length ヘッダーフィールドの存在を要求することに注意してください。

返されるプレゼンテーション記述は中程度の長さであるため, サーバーは動的に生成される場合でも常にその長さを決定できるはずであり, チャンク転送エンコーディングは不要になります。エンティティボディがある場合は Content-Length が必須ですが, これらの規則により長さが明示されなくても妥当な動作が保証されます。