12 Header Field Definitions (ヘッダーフィールド定義)
12 Header Field Definitions (ヘッダーフィールド定義)
HTTP/1.1 [2] またはここに列挙されていないその他の非標準ヘッダーフィールドは, 現時点で明確に定義された意味を持たず, 受信者は SHOULD 無視する。
表 3 は RTSP が用いるヘッダーフィールドをまとめる。型 "g" はリクエストとレスポンスの両方に現れる general request headers (一般リクエストヘッダー) を, "R" は request headers (リクエストヘッダー) を, "r" は response headers (レスポンスヘッダー) を, "e" は entity header fields (エンティティヘッダーフィールド) を示す。"support" 列に "req." とあるフィールドは, 特定メソッドについて受信者が MUST 実装しなければならない。"opt." のフィールドは任意である。すべての "req." フィールドがこの種のすべてのリクエストで送られるとは限らないことに注意。"req." は, クライアント (レスポンスヘッダーについて) とサーバー (リクエストヘッダーについて) がこれらのフィールドを MUST 実装することだけを意味する。最後の列は当該ヘッダーフィールドが意味を持つメソッドを列挙する。"entity" の指定は message body (メッセージ本文) を返すすべてのメソッドを指す。本仕様では DESCRIBE と GET_PARAMETER がこのクラスに含まれる。
| Header | type | support | methods |
|---|---|---|---|
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | r | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | all but OPTIONS, TEARDOWN |
| Cache-Control | g | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | g | req. | all |
| Content-Base | e | opt. | entity |
| Content-Encoding | e | req. | SET_PARAMETER, DESCRIBE, ANNOUNCE |
| Content-Language | e | req. | DESCRIBE, ANNOUNCE |
| Content-Length | e | req. | SET_PARAMETER, ANNOUNCE, entity |
| Content-Location | e | opt. | entity |
| Content-Type | e | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | r | req. | entity |
| CSeq | g | req. | all |
| Date | g | opt. | all |
| Expires | e | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | e | opt. | entity |
| Proxy-Authenticate | r | opt. | all |
| Proxy-Require | R | req. | all |
| Public | r | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | r | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | r | opt. | all |
| RTP-Info | r | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | all but SETUP, OPTIONS |
| Server | r | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | r | req. | all |
| User-Agent | R | opt. | all |
| Via | g | opt. | all |
| WWW-Authenticate | r | opt. | all |
RTSP ヘッダーフィールドの概要
12.1 Accept
Accept request-header field (Accept リクエストヘッダーフィールド) は, レスポンスとして受け入れ可能な presentation description (プレゼンテーション記述) の content types (コンテンツ型) を指定するのに用いられる。
プレゼンテーション記述の "level" パラメータは MIME 型登録の一部としてここではなくそこで適切に定義される。
構文は [H14.1] を参照。
使用例: Accept: application/rtsl, application/sdp;level=2
12.2 Accept-Encoding
[H14.3] を参照。
12.3 Accept-Language
[H14.4] を参照。指定する言語はプレゼンテーション記述および任意の reason phrases (理由フレーズ) に適用され, メディアコンテンツには適用されないことに注意。
12.4 Allow
Allow response header field (Allow レスポンスヘッダーフィールド) は, request-URI で識別されるリソースがサポートするメソッドを列挙する。このフィールドの目的は, リソースに関連する有効なメソッドを受信者に厳密に知らせることである。405 (Method not allowed) レスポンスには Allow ヘッダーフィールドが存在しなければならない。
使用例: Allow: SETUP, PLAY, RECORD, SET_PARAMETER
12.5 Authorization
[H14.8] を参照。
12.6 Bandwidth
Bandwidth request-header field (Bandwidth リクエストヘッダーフィールド) は, クライアントに利用可能と推定される帯域を, 正の整数として bits per second (ビット毎秒) で表す。RTSP セッション中, 例えばモデムの再トレーニングなどにより, クライアントに利用可能な帯域は変化しうる。
Bandwidth = "Bandwidth" ":" 1*DIGIT
例: Bandwidth: 4000
12.7 Blocksize
このリクエストヘッダーフィールドは, クライアントからメディアサーバーへ送られ, 特定のメディア packet size (パケットサイズ) をサーバーに求める。このパケットサイズには IP, UDP, RTP など下位層のヘッダーは含まれない。サーバーは要求より小さい blocksize (ブロックサイズ) を自由に用いてよい。サーバーは MAY, このパケットサイズを最小のメディア固有ブロックサイズの最も近い倍数に切り捨てるか, 必要に応じてメディア固有サイズで上書きしてよい。ブロックサイズは MUST, octets (オクテット) で計測した正の十進数でなければならない。値が構文的に無効な場合に限り, サーバーはエラー (416) を返す。
12.8 Cache-Control
Cache-Control general-header field (Cache-Control 一般ヘッダーフィールド) は, リクエスト/レスポンスチェーン上のすべての caching mechanisms (キャッシュ機構) が MUST 従う指令を指定するのに用いられる。
キャッシュ指令は, 当該アプリケーションにとって重要でなくても, プロキシまたはゲートウェイアプリケーションによって透過的に渡されなければならない。指令はチェーン上のすべての受信者に適用されうるからである。特定のキャッシュに対する cache-directive を指定することはできない。
Cache-Control は SETUP リクエストとそのレスポンスにのみ指定すべきである。注: Cache-Control は HTTP のようにレスポンスのキャッシュを支配するのではなく, SETUP リクエストで識別されるストリームのキャッシュを支配する。DESCRIBE へのレスポンスを除き, RTSP リクエストへのレスポンスはキャッシュ不能である。
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive |
cache-response-directive
cache-request-directive = "no-cache" |
"max-stale" |
"min-fresh" |
"only-if-cached" |
cache-extension
cache-response-directive = "public" |
"private" |
"no-cache" |
"no-transform" |
"must-revalidate" |
"proxy-revalidate" |
"max-age" "=" delta-seconds |
cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
no-cache: メディアストリームをどこにもキャッシュしてはならない (MUST NOT) ことを示す。これによりオリジンサーバーは, クライアントリクエストに対して stale (古い) レスポンスを返すよう構成されたキャッシュであってもキャッシュを防げる。
public: メディアストリームが任意のキャッシュによりキャッシュ可能であることを示す。
private: メディアストリームが単一ユーザ向けであり, shared cache (共有キャッシュ) によりキャッシュしてはならない (MUST NOT) ことを示す。private (非共有) キャッシュはメディアストリームをキャッシュしてよい。
no-transform: 中間キャッシュ (プロキシ) は特定ストリームのメディア型を変換すると有用な場合がある。例えばプロキシはキャッシュ空間の節約や低速リンク上のトラフィック削減のために動画形式間で変換しうる。しかし, 特定種のアプリケーション向けストリームにこれらの変換が適用されると重大な運用上の問題が生じうる。例えば医用画像, 科学データ解析, エンドツーエンド認証を用いるアプリケーションはすべて, オリジナルの entity-body とビット単位で同一のストリームを受け取ることに依存する。したがって, レスポンスに no-transform 指令が含まれる場合, 中間キャッシュまたはプロキシはストリームの encoding (符号化) を変更してはならない (MUST NOT)。HTTP とは異なり, RTSP は現時点では部分的変換, 例えば別言語への翻訳を許さない。
only-if-cached: 極めて悪いネットワーク接続時など, クライアントはキャッシュに現在格納されているメディアストリームのみを返し, オリジンサーバーから受信しないことを望むことがある。これを行うため, クライアントはリクエストに only-if-cached 指令を含めてよい。キャッシュがこの指令を受け取った場合, SHOULD, リクエストの他の制約と整合するキャッシュ済みメディアストリームで応答するか, 504 (Gateway Timeout) ステータスで応答する。ただし, 複数のキャッシュが内部接続の良い統一システムとして運用されている場合, そのキャッシュ群の内部ではそのようなリクエストを転送してもよい (MAY)。
max-stale: クライアントが有効期限を過ぎたメディアストリームを受け入れる意思があることを示す。max-stale に値が割り当てられていれば, クライアントは有効期限を指定秒数を超えて過ぎたレスポンスまで受け入れる。max-stale に値がなければ, クライアントは任意の経過時間の stale レスポンスを受け入れる。
min-fresh: クライアントが, 鮮度寿命が現在の経過時間に指定秒数を加えた値以上であるメディアストリームを受け入れる意思があることを示す。すなわちクライアントは, 少なくとも指定秒数の間まだ鮮度が保たれるレスポンスを望む。
must-revalidate: キャッシュが SETUP レスポンスで must-revalidate 指令を受け取った場合, そのキャッシュは, エントリが stale になった後, オリジンサーバーとの再検証なしに後続リクエストに応答するためにそのエントリを用いてはならない (MUST NOT)。すなわちオリジンサーバーの Expires のみに基づいてキャッシュレスポンスが stale であると判断される場合, キャッシュは毎回エンドツーエンドの再検証を行わなければならない。
12.9 Conference
このリクエストヘッダーフィールドは, 事前に確立された会議と RTSP ストリームとの論理接続を確立する。同一 RTSP セッションについて conference-id (会議 ID) を変更してはならない。
Conference = "Conference" ":" conference-id
例: Conference: [email protected]%20Starr
conference-id が無効な場合, レスポンスコード 452 (452 Conference Not Found) が返される。
12.10 Connection
[H14.10] を参照。
12.11 Content-Base
[H14.11] を参照。
12.12 Content-Encoding
[H14.12] を参照。
12.13 Content-Language
[H14.13] を参照。
12.14 Content-Length
このフィールドはメソッドのコンテンツ長 (最後のヘッダーに続く二重 CRLF 以降) を含む。HTTP とは異なり, メッセージのヘッダー部分を超えてコンテンツを運ぶすべてのメッセージに MUST 含まれなければならない。欠落している場合, デフォルト値ゼロが仮定される。解釈は [H14.14] に従う。
12.15 Content-Location
[H14.15] を参照。
12.16 Content-Type
[H14.18] を参照。RTSP に適したコンテンツ型は, 実務上プレゼンテーション記述と parameter-value types (パラメータ値型) に限定されうることに注意。
12.17 CSeq
CSeq フィールドは RTSP request-response pair (リクエスト・レスポンス対) のシーケンス番号を指定する。このフィールドはすべてのリクエストとレスポンスに MUST 存在しなければならない。与えられたシーケンス番号を含むすべての RTSP リクエストについて, 同じ番号を持つ対応するレスポンスが存在する。再送されたリクエストはオリジナルと同じシーケンス番号を含めなければならない (すなわち同一リクエストの再送ではシーケンス番号を増やさない)。
12.18 Date
[H14.19] を参照。
12.19 Expires
Expires entity-header field (Expires エンティティヘッダーフィールド) は, その日時以降に記述またはメディアストリームを stale と見なすべき日時を与える。解釈はメソッドに依存する。
DESCRIBE レスポンス: Expires ヘッダーは, その日時以降に記述を stale と見なすべきことを示す。
stale cache entry (古いキャッシュエントリ) は, 通常, オリジンサーバー (またはエンティティの新鮮なコピーを持つ中間キャッシュ) との検証なしにキャッシュ (プロキシキャッシュまたは user agent cache (ユーザエージェントキャッシュ)) により返されてはならない。有効期限モデルの詳細は第 13 節を参照。
Expires フィールドの存在は, 元のリソースがその時刻に, その前に, またはその後に変化または消滅することを意味しない。
形式は [H3.3] の HTTP-date で定義される絶対日時であり, MUST RFC1123-date 形式でなければならない。
Expires = "Expires" ":" HTTP-date
使用例:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 クライアントとキャッシュは, 他の無効な日付形式, 特に値 "0" を含め, 過去に発生した (すなわち "すでに期限切れ") ものとして扱わなければならない (MUST)。
レスポンスを "すでに期限切れ" と印付けるには, オリジンサーバーは Date ヘッダー値と等しい Expires 日付を用いるべきである。"期限なし" と印付けるには, オリジンサーバーはレスポンス送信時刻から約 1 年後の Expires 日付を用いるべきである。RTSP/1.0 サーバーは 1 年を超える未来の Expires 日付を送るべきではない。
デフォルトではキャッシュ不能なメディアストリームについて, 将来の日時値を持つ Expires ヘッダーフィールドの存在は, Cache-Control ヘッダーフィールド (第 12.8 節) で別途示されない限り, メディアストリームがキャッシュ可能であることを示す。
12.20 From
[H14.22] を参照。
12.21 Host
この HTTP リクエストヘッダーフィールドは RTSP では不要である。送られてきた場合は黙って無視すべきである。
12.22 If-Match
[H14.25] を参照。
このフィールドは, プレゼンテーション記述の完全性を保証するのに特に有用である。記述が RTSP 以外の手段 (HTTP など) で取得される場合も, サーバー実装が DESCRIBE メッセージと SETUP メッセージの間で記述の完全性を保証する場合も同様である。
identifier (識別子) は opaque identifier (不透明識別子) であり, 特定のセッション記述言語に特有ではない。
12.23 If-Modified-Since
If-Modified-Since request-header field は DESCRIBE と SETUP メソッドと共に用いられ, 条件付きにする。要求された variant (バリアント) がこのフィールドで指定された時刻以降に変更されていなければ, サーバーは記述を返さない (DESCRIBE), またはストリームを確立しない (SETUP)。代わりに message-body のない 304 (not modified) レスポンスが返される。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
フィールドの例:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
12.24 Last-Modified
Last-Modified entity-header field は, オリジンサーバーがプレゼンテーション記述またはメディアストリームが最後に変更されたと考える日時を示す。[H14.29] を参照。DESCRIBE または ANNOUNCE ではヘッダーフィールドは記述の最終変更日時を, SETUP ではメディアストリームのそれを示す。
12.25 Location
[H14.30] を参照。
12.26 Proxy-Authenticate
[H14.33] を参照。
12.27 Proxy-Require
Proxy-Require ヘッダーは, プロキシが MUST サポートしなければならない proxy-sensitive features (プロキシ依存機能) を示すのに用いられる。プロキシがサポートしない Proxy-Require ヘッダーの機能はすべて, サポートされない場合はプロキシがクライアントに対して否定的に確認しなければならない (MUST)。サーバーはこのフィールドを Require フィールドと同一に扱うべきである。
このメッセージの機構と使用例の詳細は第 12.32 節を参照。
12.28 Public
[H14.35] を参照。
12.29 Range
このリクエストおよびレスポンスヘッダーフィールドは時間の範囲を指定する。範囲は複数の単位で指定できる。本仕様は smpte (第 3.5 節), npt (第 3.6 節), clock (第 3.7 節) の範囲単位を定義する。RTSP 内では byte ranges (バイト範囲) [H14.36.1] は意味をなさず, MUST NOT 用いられてはならない。ヘッダーには操作を有効にする UTC の時刻を指定する time パラメータを含めてもよい。Range ヘッダーをサポートするサーバーは NPT 範囲形式を MUST 理解し, SMPTE 範囲形式を SHOULD 理解しなければならない。Range レスポンスヘッダーは, 実際に再生または録画されている時間範囲を示す。Range ヘッダーが理解できない時間形式で与えられた場合, 受信者は "501 Not Implemented" を返すべきである。
範囲は半開区間であり, 下端を含み上端を含まない。すなわち範囲 a–b は時刻 a で正確に始まり, b の直前で止まる。動画フレームや音声フレームなど media unit (メディアユニット) の開始時刻のみが関連する。例として, 動画フレームが 40 ms ごとに生成されるとする。範囲 10.0–10.1 は 10.0 以降に開始する動画フレームを含み, 10.08 に開始するフレームも含む。たとえそれが区間を超えて継続してもである。一方 10.0–10.08 の範囲は 10.08 に開始するフレームを除外する。
Range = "Range" ":" 1#ranges-specifier [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
例: Range: clock=19960213T143205Z-;time=19970123T143720Z
記法は HTTP/1.1 [2] の byte-range ヘッダーに用いられるものに類似している。クライアントがメディアオブジェクトから抜粋を選択し, 与えられた点から末尾まで, および現在位置から与えられた点まで再生することを許す。再生開始は将来の任意の時刻にスケジュールできるが, サーバーは長期間のアイドルにサーバーリソースを保持することを拒否しうる。
12.30 Referer
[H14.37] を参照。URL はプレゼンテーション記述の URL を指し, 通常 HTTP で取得される。
12.31 Retry-After
[H14.38] を参照。
12.32 Require
Require ヘッダーは, クライアントがサーバーに対し, サポートしているかもしれない, していないかもしれないオプションを問い合わせるのに用いられる。サーバーは MUST, このヘッダーに対し Unsupported ヘッダーを用いてサポートされていないオプションを否定的に確認して応答しなければならない。
これにより, すべてのオプションが双方に理解されるときはクライアント・サーバー相互作用が遅延なく進み, オプションが理解されない場合にのみ遅くなる (上記の場合のように) ことが保証される。適合の良いクライアント・サーバー対では相互作用が速く進み, 交渉機構でしばしば必要となる往復を省ける。さらに, クライアントがサーバーが理解しない機能を要求するときの状態の曖昧さも取り除かれる。
Require = "Require" ":" 1#option-tag
例: C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Require: funky-feature Funky-Parameter: funkystuff
S->C: RTSP/1.0 551 Option not supported CSeq: 302 Unsupported: funky-feature
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0 CSeq: 303
S->C: RTSP/1.0 200 OK CSeq: 303
この例では "funky-feature" が feature tag (機能タグ) であり, 架空の Funky-Parameter フィールドが必要であることをクライアントに示す。"funky-feature" と Funky-Parameter の関係は RTSP 交換で伝達されない。その関係は "funky-feature" の不変の属性であり, 毎回の交換で送るべきではないからである。
プロキシおよびその他の中間装置は, このフィールドで理解できない機能を SHOULD 無視する。特定の拡張が中間装置のサポートを要求する場合, 拡張は代わりに Proxy-Require フィールドでタグ付けすべきである (第 12.27 節参照)。
12.33 RTP-Info
このフィールドは PLAY レスポンスで RTP 固有のパラメータを設定するのに用いられる。
url: 以下の RTP パラメータが対応する stream URL (ストリーム URL) を示す。
seq: ストリームの最初のパケットの sequence number (シーケンス番号) を示す。クライアントがシーク時にパケットを適切に扱えるようにする。クライアントはこの値を用いて, シーク前に生成されたパケットとシーク後に生成されたパケットを区別する。
rtptime: Range レスポンスヘッダー内の時刻値に対応する RTP timestamp (RTP タイムスタンプ) を示す。(注: aggregate control (集約制御) では, 特定のストリームが返されたまたは暗黙の範囲時刻値に対して実際にパケットを生成しないことがある。したがって seq で示されたシーケンス番号のパケットが実際に rtptime で示されたタイムスタンプを持つ保証はない。) クライアントはこの値を用いて RTP 時刻から NPT への写像を計算する。
RTP タイムスタンプから NTP タイムスタンプ (壁時計) への写像は RTCP 経由で得られる。しかしこの情報だけでは RTP タイムスタンプから NPT への写像を生成するには不十分である。さらに, 必要な瞬間 (起動直後またはシーク後) にこの情報が確実に利用可能であり確実に届くようにするため, この写像は RTSP 制御チャネルに置かれる。
長時間連続したプレゼンテーションの drift (ドリフト) を補償するため, RTSP クライアントはさらに NPT を NTP に写像すべきであり, 初期の RTCP sender reports (送信者レポート) で写像を行い, 後続のレポートで写像に対するドリフトを確認する。
構文:
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT
例:
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
12.34 Scale
scale 値 1 は, 通常の順方向視聴レートでの通常再生または録音を示す。1 でなければ, 値は通常視聴レートに対する比率に対応する。例えば比率 2 は通常の 2 倍の視聴レート ("早送り") を, 0.5 は半分の視聴レートを示す。言い換えれば比率 2 では normal play time が壁時計レートの 2 倍で増加する。壁時計で 1 秒経つごとに, 2 秒分のコンテンツが配送される。負の値は逆方向を示す。
Speed パラメータで別途要求されない限り, データレートは SHOULD NOT 変更される。スケール変更の実装はサーバーとメディア型に依存する。動画ではサーバーはキーフレームのみ, または選択したキーフレームのみを配送しうる。音声ではピッチを保ちながら time-scale するか, 望ましくはないが音声断片を配送しうる。
サーバーは視聴レートに近似しようとすべきだが, サポートするスケール値の範囲を制限しうる。レスポンスは MUST, サーバーが選んだ実際のスケール値を含まなければならない。
リクエストに Range パラメータが含まれる場合, 新しいスケール値はその時刻で有効になる。
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
通常レートの 3.5 倍で逆再生する例:
Scale: -3.5
12.35 Speed
このリクエストヘッダーフィールドのパラメータは, サーバーに対し, サーバーの能力と意志に応じて, 指定速度でクライアントにデータを配送するよう要求する。サーバーによる実装は OPTIONAL (任意) である。デフォルトはストリームのビットレートである。
パラメータ値は十進比率で表され, 例えば 2.0 は通常の 2 倍の速さでデータを配送することを示す。速度ゼロは無効である。リクエストに Range パラメータが含まれる場合, 新しい速度値はその時刻で有効になる。
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
例: Speed: 2.5
このフィールドの使用はデータ配送に用いられる帯域を変える。プレゼンテーションをより高いまたは低いレートでプレビューする必要がある特定状況向けである。実装者は, セッションの帯域が (RTSP 以外の手段で) 事前に交渉されている可能性があり, したがって再交渉が必要になりうることを念頭に置くべきである。データが UDP で配送される場合, パケット損失率を追跡する手段として RTCP などを用いることを強く推奨する。
12.36 Server
[H14.39] を参照。
12.37 Session
このリクエストおよびレスポンスヘッダーフィールドは, メディアサーバーが SETUP レスポンスで開始し, presentation URL に対する TEARDOWN で終了する RTSP セッションを識別する。session identifier (セッション識別子) はメディアサーバーが選ぶ (第 3.4 節参照)。クライアントが Session 識別子を受け取ったら, そのセッションに関連するすべてのリクエストで MUST それを返さなければならない。サーバーがセッションを識別する他の手段 (動的に生成された URL など) を持つ場合, セッション識別子を設定する必要はない。
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
timeout パラメータはレスポンスヘッダーにのみ許される。サーバーは, 活動不足によりセッションを閉じる前に RTSP コマンドの間でどれだけ待つ用意があるかをクライアントに示すのに用いる (付録 A 参照)。タイムアウトは秒で計測され, デフォルトは 60 秒 (1 分) である。
セッション識別子は transport sessions (トランスポートセッション) または接続にまたがって RTSP セッションを識別することに注意。複数の RTSP URL の制御メッセージは単一の RTSP セッション内で送られてよい。したがってすべてのストリームが同一サーバーから来る限り, クライアントはプレゼンテーションを構成する多くのストリームを同じセッションで制御してよい (第 14 節の例参照)。しかし同一クライアントから同一 URL に対する複数の "user" sessions (ユーザセッション) は MUST 異なるセッション識別子を用いなければならない。
セッション識別子は, 同一クライアントから同一 URL への複数の配送リクエストを区別するために必要である。
セッション識別子が無効な場合, レスポンス 454 (Session Not Found) が返される。
12.38 Timestamp
Timestamp general header (Timestamp 一般ヘッダー) は, クライアントがサーバーにリクエストを送った時刻を記述する。タイムスタンプ値の意味はクライアントにのみあり, 任意の時間軸を用いてよい。サーバーは MUST まったく同じ値をエコーし, MAY, そのリクエストを受信してから経過した秒数を示す浮動小数点数を, 正確な情報を持つ場合に付加してよい。タイムスタンプはクライアントがサーバーへの round-trip time (往復時間) を計算し再送のタイムアウト値を調整するのに用いられる。
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
12.39 Transport
このリクエストヘッダーは, 使用する transport protocol (トランスポートプロトコル) と, 単一ストリームの destination address (宛先アドレス), compression (圧縮), multicast time-to-live (マルチキャスト TTL), destination port (宛先ポート) などのパラメータ設定を示す。プレゼンテーション記述でまだ決まっていない値を設定する。
Transports はコンマ区切りで, 優先順に列挙される。各トランスポートにはセミコロンで区切ってパラメータを追加できる。
Transport ヘッダーは MAY また特定のトランスポートパラメータを変更するのに用いられてよい。サーバーは MAY 既存ストリームのパラメータ変更を拒否してよい。
サーバーは MAY 実際に選ばれた値を示す Transport レスポンスヘッダーをレスポンスで返してよい。
Transport リクエストヘッダーフィールドは, クライアントが受け入れ可能なトランスポートオプションのリストを含みうる。その場合サーバーは MUST 実際に選ばれた単一のオプションを返さなければならない。
transport specifier (トランスポート指定子) の構文は
transport/profile/lower-transport である。
"lower-transport" のデフォルト値はプロファイルに固有である。RTP/AVP ではデフォルトは UDP である。
以下はトランスポートに関連する設定パラメータである。
General parameters (一般パラメータ):
unicast | multicast: ユニキャストまたはマルチキャスト配送のどちらを試みるかを排他的に示す。デフォルト値は multicast である。ユニキャストとマルチキャストの両方を扱えるクライアントは MUST, それぞれに別パラメータを持つ 2 つの完全な transport-spec を含めてその能力を示さなければならない。
destination: ストリームが送られるアドレス。クライアントは destination パラメータでマルチキャストアドレスを指定してよい。remote-controlled denial-of-service attack (遠隔制御型サービス拒否攻撃) の意図しない加害者になるのを避けるため, サーバーは SHOULD クライアントを認証し, クライアントがサーバーが選んだアドレス以外にメディアストリームを向けることを許可する前にそのような試みを SHOULD 記録する。RTSP コマンドが UDP 経由で発行される場合は特に重要だが, 実装は TCP 単独をクライアント識別の確実な手段として頼ってはならない。サーバーは SHOULD NOT, コマンドの発信元と異なるアドレスにクライアントがメディアストリームを向けることを許可する。
source: ストリームの source address (送信元アドレス) が RTSP endpoint address (RTSP エンドポイントアドレス) (再生ではサーバー, 録音ではクライアント) から導出できない場合, source を指定してもよい (MAY)。
この情報は SDP 経由でも利用可能である。しかしこれはメディア初期化よりトランスポートの機能であるため, 権威ある情報源は SETUP レスポンスにあるべきである。
layers: このメディアストリームに用いるマルチキャスト層の数。層は destination アドレスから連続アドレスへ送られる。
mode: mode パラメータはこのセッションでサポートすべきメソッドを示す。有効な値は PLAY と RECORD である。与えられなければデフォルトは PLAY である。
append: mode パラメータに RECORD が含まれる場合, append パラメータはメディアデータを既存リソースに上書きせず追記すべきであることを示す。追記が要求されサーバーがサポートしない場合, サーバーは URI で識別されるリソースを上書きするのではなく MUST リクエストを拒否しなければならない。mode に RECORD が含まれない場合 append パラメータは無視される。
interleaved: interleaved パラメータは, 制御ストリームが用いるプロトコルでメディアストリームを制御ストリームと混在させることを意味し, 機構は第 10.12 節で定義される。引数は $ 文で用いる channel number (チャネル番号) を与える。メディアストリームのトランスポート選択で必要な場合, 例えば interleaved=4-5 のように範囲として指定してよい。
これにより RTP/RTCP を UDP の場合と同様に扱える。すなわち RTP に 1 チャネル, RTCP にもう 1 チャネルである。
Multicast specific (マルチキャスト固有):
ttl: multicast time-to-live (マルチキャスト生存時間)
RTP Specific (RTP 固有):
port: マルチキャストセッションの RTP/RTCP ポート対を与える。範囲で指定する, 例: port=3456-3457。
client_port: メディアデータと制御情報の受信にクライアントが選んだユニキャスト RTP/RTCP ポート対を与える。範囲で指定する, 例: client_port=3456-3457。
server_port: メディアデータと制御情報の受信にサーバーが選んだユニキャスト RTP/RTCP ポート対を与える。範囲で指定する, 例: server_port=3456-3457。
ssrc: ssrc パラメータは, メディアサーバーが用いるべき (リクエスト) または用いる (レスポンス) RTP SSRC [24, Sec. 3] 値を示す。このパラメータはユニキャスト送信にのみ有効である。メディアストリームに関連付ける synchronization source (同期源) を識別する。
Transport = "Transport" ":" 1#transport-spec
transport-spec = transport-protocol/profile[/lower-transport] *parameter
transport-protocol = "RTP"
profile = "AVP"
lower-transport = "TCP" | "UDP"
parameter = ( "unicast" | "multicast" ) |
";" "destination" [ "=" address ] |
";" "interleaved" "=" channel [ "-" channel ] |
";" "append" |
";" "ttl" "=" ttl |
";" "layers" "=" 1*DIGIT |
";" "port" "=" port [ "-" port ] |
";" "client_port" "=" port [ "-" port ] |
";" "server_port" "=" port [ "-" port ] |
";" "ssrc" "=" ssrc |
";" "mode" "=" "\"" 1#Method "\"" | Method
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
channel = 1*3(DIGIT)
address = host
例: Transport: RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
Transport ヘッダーは単一の RTP ストリームの記述に限定される。(RTSP は複数ストリームを単一エンティティとして制御することもできる。) これを RTSP の一部とし大量のセッション記述形式に頼らないことで, ファイアウォールの設計が大きく単純化される。
12.40 Unsupported
Unsupported レスポンスヘッダーはサーバーがサポートしない機能を列挙する。機能が Proxy-Require フィールド (第 12.32 節) で指定され, クライアントとサーバーの間のパス上にプロキシがある場合, プロキシは MUST エラーメッセージ "551 Option Not Supported" を伴う応答メッセージを挿入しなければならない。
使用例は第 12.32 節を参照。
12.41 User-Agent
[H14.42] を参照。
12.42 Vary
[H14.43] を参照。
12.43 Via
[H14.44] を参照。
12.44 WWW-Authenticate
[H14.46] を参照。