リアルタイム・ストリーミング・プロトコル (RTSP) (調査と解説)

リアルタイム・ストリーミング・プロトコル (Real Time Streaming Protocol, RTSP) は IETF において標準化されたリアルタイム性のあるデータの配布 (ストリーミング) を制御するためのプロトコルである．ここでは RTSP について説明したあと，RTSP がもたない巻き戻し，早送りの機能についても論じる．

1998 年 4 月にその最初の版が RFC 2326 (H. Schulzrinne, A. Rao, R. Lanphier: Real Time Streaming Protocol (RTSP)) として標準化されたが，様々な問題点があることが指摘され，2003 年 9 月現在，改訂中であり，RTSP に関する最新のドキュメントは 2003 年 10 月に発行されたインターネット・ドラフト draft-ietf-mmusic-rfc2326bis-05 (H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, A. Narasimhan: Real Time Streaming Protocol (RTSP)) である．ここでは RFC 2326 を中心とし，必要に応じて draft-ietf-mmusic-rfc2326bis-05 も参照しながら，RTSP に関する調査結果を記述する．

1. RTSP の概要

RTSP はオーディオ，ビデオなどのマルチメディア・データをふくむサーバを遠隔操作するためのプロトコルである．したがって，SIP とはちがって RTSP においてはサーバとクライアントとが明確にくべつされ，データのながれは基本的にサーバからクライアントへの一方向であるが，サーバからクライアントに送付する要求も定義されている．すなわち，要求-応答モデルとしてみると，サーバとクライアントの役割が逆転することもある．

サーバからクライアントへのデータ転送 (RTSP においてはプレゼンテーションとよばれる) には通常 RTP が使用されるが，それに限定されてはいない． RTSP によって制御されるデータのながれに関しては “RTSP セッション” が存在するが，RTSP 自体には，SIP と同様にセッションの概念はない． SIP と同様，RTSP も HTTP に似せてある． RTSP の下位のプロトコルとしては，SIP とはちがって，TCP のように高信頼なプロトコルの使用が前提とされている．ただし，前記の draft-ietf-mmusic-rfc2326bis-05 においては低信頼なプロトコルを使用できるようにする方向性が示されている． RTSP がサポートする操作はつぎの 3 つである．

(1) メディアサーバからのメディアのとりだし: RTSP を使用してメディア・データをとりだすことができる．そのきっかけとしてよくあるのは WWW においてメディアへのリンクをクリックすることであり，この場合プレゼンテーションの記述は HTTP によってメディアサーバにあたえられる．
(2) メディアサーバを会議に参加させること: マルチメディア会議においてメディアを再生したり，会議を記録したりするために RTSP を使用してメディアサーバを会議に参加させることができる．会議自体の制御はたとえば SIP によっておこなわれる．
(3) メディアをプレゼンテーションにくわえること: RTSP を使用してとくにライブ・プレゼンテーションにおいて，メディアをプレゼンテーションに参加させることができる． RTSP をあつかうメディアサーバは RTSP セッションの状態を管理する必要がある．

RFC 2326 にはセキュリティに関する記述がわずかしかないが，前記の draft-ietf-mmusic-rfc2326bis-05 においてはセキュリティに関する考察やセキュリティやプライバシーを守るための機構についても記述されている．これらについては ??? 節において述べる．

2. 要求メッセージの種類

おもな要求メッセージのメソッドはつぎの 5 種類である．これらはいずれもクライアントからサーバに対して (だけ) 送信される．

(1) SETUP

サーバにストリームのための資源をわりあてて RTSP のセッションを開始することを要求するためのメソッドである． SETUP メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-05 から引用する．

     C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
           CSeq: 302
           Transport: RTP/AVP;unicast;client_port=4588-4589，
                      RTP/AVP/TCP;unicast;interleave=0-1

(2) PLAY と RECORD

SETUP メッセージによってわりあてられた資源を使用してメディアの再生または記録を開始することを要求するためのメソッドである．まず，PLAY メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-05 から引用する．

     C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15, npt=20-25, npt=30-

ここでは，Range ヘッダによって，NPT (Normal Play Time) すなわち標準速度で再生したときの時間が 10 から 15 秒，20 から 25 秒，30 秒以降の範囲について再生することを指定している．つぎに，RECORD メッセージの例を draft-ietf-mmusic-rfc2326bis-04 から引用する． RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 CSeq: 954 Session: 12345678 Conference: 128.16.64.19/32492374 このメッセージでは指定した会議 (128.16.64.19/32492374) の内容を記録することを指示している．

(3) PAUSE

サーバの資源を解放することなく，一時的にストリームを停止させるためのメソッドである．一時停止したストリームを再開させるには Range ヘッダのない PLAY メッセージを使用する．PAUSE メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678

(4) TEARDOWN

サーバの資源を解放し，RTSP セッションを終了させるためのメソッドである． TEARDOWN メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678

これ以外の要求メッセージとして RFC 2326 においてつぎのものが定義されている．これらのうち ANNOUNCE, GET_PARAMETER, OPTIONS, SET_PARAMETER はクライアント，サーバのどちらからも送信することができる．また，REDIRECT はサーバからクライアントに対してだけ送信される．他のメソッドはクライアントからサーバに対してだけ送信される．

(5) DESCRIBE

プレゼンテーションやメディア・オブジェクトに関する記述を要求するためのメソッドである． DESCRIBE メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/rtsl, application/mheg

ここでは rtsp://server.example.com/fizzle/foo というプレゼンテーションに関する記述を要求している．サーバはこれに対して通常 SDP による記述をふくむ応答をかえす．

(6) ANNOUNCE

クライアントからサーバに対して送信されるときは，プレゼンテーションやメディア・オブジェクトに関する記述をサーバにあたえるためのメソッドである．逆にサーバからクライアントに対して送信されるときは，セッション記述をリアルタイムに書き換える．クライアントが送信する ANNOUNCE メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Content-Type: application/sdp
Content-Length: 332

v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31

ここではプレゼンテーションの記述をサーバに送信している．

(7) GET_PARAMETER

プレゼンテーションやストリームのパラメータ値を問い合わせるためのメソッドである． GET_PARAMETER メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-05 から引用する (ただし，Content-Length の値を訂正した)．

GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 26

packets_received
jitter

この要求メッセージは受信したパケット数とジッタの値とを問い合わせている．

(8) OPTIONS

SIP の OPTIONS メソッドと同様にサーバの能力のといあわせなどのためのメソッドである． OPTIONS メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

OPTIONS * RTSP/1.0
CSeq: 1
User-Agent: PhonyClient 1.2
Require: implicit-play
Proxy-Require: gzipped-messages
Supported: play-basic

(9) REDIRECT

クライアントに対して他の場所のサーバに接続することをもとめるメソッドである． REDIRECT メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
Session: uZ3ci0K+Ld-M

この要求メッセージにおいては，代替サーバとして rtsp://bigserver.-com:8001 を指定している．

(10) SET_PARAMETER

プレゼンテーションやストリームのパラメータ値をセットするためのメソッドである． SET_PARAMETER メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters

barparam: barstuff

この要求メッセージは barparam というパラメータの値を “barstuff” とすることを要求している．

以上の 10 個のメソッドのほかに，前記の draft-ietf-mmusic-rfc2326bis-04 においてはつぎのメソッドが追加されている．

(11) PING

クライアント，サーバのいずれからも送信することができ，相手が動作中 (alive) かどうかを確認するために使用されるメソッドである． PING メッセージの例を前記の draft-ietf-mmusic-rfc2326bis-04 から引用する．

PING * RTSP/1.0
CSeq: 123
Session:12345678

3. 応答メッセージの種類

応答メッセージは SIP におけるのと同様に，つぎのように分類されている．

(1) 情報的 (1xx): 100 番台のメッセージは，要求をうけとり，処理中であることをあらわす情報的 (informational) メッセージである．情報的メッセージとして定義されているのは “100 Continue” だけである．
(2) 成功 (2xx): 200 番台のメッセージは，要求が受理されたことをあらわす成功メッセージである．成功メッセージとしてはつぎのものが定義されている: “200 OK” (成功), “201 Created” (生成された．記録の場合), “250 Low on Storage Space” (ストレージがすくないがとりあえず成功．記録の場合)．
(3) リダイレクション (3xx): 300 番台のメッセージは，要求を実行するためにはクライアントが動作する必要があることをあらわすリダイレクション・メッセージである．リダイレクション・メッセージとしてはつぎのものが定義されている: “300 Multiple Choices” (複数のリダイレクト候補あり), “301 Moved Permanently” (恒久的に移動), “302 Found”, “303 See Other” (他を参照), “305 Use Proxy” (プロキシを使用せよ), “350 Going Away”, “351 Load Balancing”．
(4) クライアント・エラー (4xx): 400 番台のメッセージは，要求にエラーがあって失敗したことをあらわすクライアント・エラー・メッセージである．クライアント・エラー・メッセージとしてはつぎのものが定義されている: “400 Bad Request”, “401 Unauthorized”, “402 Payment Required”, “403 Forbidden”, “404 Not Found”, “405 Method Not Allowed”, “406 Not Acceptable”, “407 Proxy Authentication Required”, “408 Request Timeout”, “410 Gone”, “411 Length Required”, “412 Precondition Failed”, “413 Request Entity Too Large”, “414 Request-URI Too Long”, “415 Unsupported Media Type”, “451 Parameter Not Understood”, “452 reserved”, “453 Not Enough Bandwidth”, “454 Session Not Found”, “455 Method Not Valid In This State”, “456 Header Field Not Valid”, “457 Invalid Range”, “458 Parameter Is Read-Only”, “459 Aggregate Operation Not Allowed”, “460 Only Aggregate Operation Allowed”, “461 Unsupported Transport”, “462 Destination Unreachable”．
(5) サーバ・エラー (5xx): 500 番台のメッセージはサーバにおいてエラーが発生したことをあらわすサーバ・エラー・メッセージである．サーバ・エラー・メッセージとしてはつぎのものが定義されている: “500 Internal Server Error”, “501 Not Implemented”, “502 Bad Gateway”, “503 Service Unavailable”, “504 Gateway Timeout”, “505 RTSP Version Not Supported”, “551 Option not support”．

Keywords: 巻き戻し, 巻戻し, まきもどし, 早送り, はやおくり

調査と解説