[ Top page ]

« H.323 -- ITU-T におけるリアルタイム通信のセッション制御プロトコル | メイン | ハイパーテキスト転送プロトコル (HTTP) とクッキー »

セッション制御

リアルタイム・ストリーミング・プロトコル (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”.

4. RTSP における標準的なシーケンス

以下の例は前記の draft-ietf-mmusic-rfc2326bis-05 から引用したものであり,クライアント C がメディアサーバ V (video.example.com) から映画をうけとるときのシーケンスである. メディア記述は Web サーバ W に格納されている.

C->W:	GET /twister.sdp HTTP/1.1
	Host: www.example.com
	Accept: application/sdp

W->C:	HTTP/1.0 200 OK
	Date: 23 Jan 1997 15:35:06 GMT
	Content-Type: application/sdp

	v=0
	o=- 2890844526 2890842807 IN IP4 192.16.24.202
	s=RTSP Session
	e=adm@example.com
	m=audio 0 RTP/AVP 0
	a=control:rtsp://audio.example.com/twister/audio.en
	m=video 0 RTP/AVP 31
	a=control:rtsp://video.example.com/twister/video

C->A:	SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
	CSeq: 1
	User-Agent: PhonyClient/1.2
	Transport: RTP/AVP/UDP;unicast;client_port=3056-3057

A->C:	RTSP/1.0 200 OK
	CSeq: 1
	Session: 12345678
	Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
	           server_port=5000-5001

C->V:	SETUP rtsp://video.example.com/twister/video RTSP/1.0
	CSeq: 1
	User-Agent: PhonyClient/1.2
	Transport: RTP/AVP/UDP;unicast;client_port=3058-3059

V->C:	RTSP/1.0 200 OK
	CSeq: 1
	Session: 23456789
	Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
	           server_port=5002-5003

C->V:	PLAY rtsp://video.example.com/twister/video RTSP/1.0
	CSeq: 2
	User-Agent: PhonyClient/1.2
	Session: 23456789
	Range: smpte=0:10:00-

V->C:	RTSP/1.0 200 OK
	CSeq: 2
	Session: 23456789
	Range: smpte=0:10:00-0:20:00
	RTP-Info: url=rtsp://video.example.com/twister/video;
          seq=12312232;rtptime=78712811

C->A:	PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
	CSeq: 2
	User-Agent: PhonyClient/1.2
	Session: 12345678
	Range: smpte=0:10:00-

A->C:	RTSP/1.0 200 OK
	CSeq: 2
	User-Agent: PhonyClient/1.2
	Session: 12345678
	Range: smpte=0:10:00-0:20:00
	RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
		seq=876655;rtptime=1032181

C->A:	TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
	CSeq: 3
	User-Agent: PhonyClient/1.2
	Session: 12345678

A->C:	RTSP/1.0 200 OK
	CSeq: 3

C->V:	TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
	CSeq: 3
	User-Agent: PhonyClient/1.2
	Session: 23456789

V->C:	RTSP/1.0 200 OK
	CSeq: 3

5. RTSP におけるセッションの概念

前記のインターネット・ドラフト draft-ietf-mmusic-rfc2326bis-05 においては RTSP セッションという概念が示されている. RTSP セッションは要求メッセージおよび応答メッセージの Session ヘッダによって識別される. RTSP セッションは成功した SETUP 要求の結果として生成され,それに対する応答に含まれる Session ヘッダにおいてセッション識別子 (idedntifier) がクライアントに通知される. RTSP セッションは TEARDOWN またはタイムアウトによって終了する. セッション識別子があるために,1 個のクライアントのへの複数のストリーム配信を区別することができる.

6. RTSP API の例

RTSP 単独の API ではないが,Java Media Framework (JMF) は RTSP の機能を含んでいる. すなわち,JMF においてメディアを再生する際にはまず,次のようにして再生器 (player) を生成する.

Manager.createPlayer(URL);

ここで URL には再生するべきファイルの URL を指定する. URL において指定可能なプロトコルとして,file:, http:, rtp:, rtsp: などがある. すなわち,再生器があるのと同一のコンピュータ上のファイルを指定することもできるし,HTTP, RTP, RTSP などのプロトコルによってアクセスされるネットワーク上のファイルを指定することもできる. 生成された再生器に対しては次のような操作を行うことができる.

(1) start()
再生を開始する.
(2) syncStart(time)
時刻を指定して,他のメディアと同期しつつ再生を開始する.
(3) stop()
再生を停止する.
(4) setMediaTime()
停止している再生器に対して,メディア時刻を設定する. メディアの途中からの再生を準備する.

他にも様々な操作が可能だが,ここでは省略する. これらの操作は RTSP によってアクセスされるメディアにおいては PLAY,TEARDOWN などのメソッドによって実現されていると考えられる.

7. 巻き戻しや早送りの機能について

RTSP を使用することによってメディアの再生,停止,一時停止を指示することができる. しかし,テープレコーダや CD/DVD プレヤと比較したときには,巻き戻しや早送りという重要な機能がないことに気づく. PLAY メソッドにおいて再生する範囲を指定することができるので,通常はそれによって巻き戻し,早送りの機能を代替すればよいと考えられる. しかし,テープレコーダを使用する場面を考えてみれば,それだけでは十分でないことがわかるだろう.

巻き戻しや早送りの機能をそなえたプロトコルとして,たとえば 2003 年 5月に発行されたインターネット・ドラフト draft-shanmugham-mrcp-04 (S. Shanmugham, P. Monaco, B. Eberman: A Media Resource Control Protocol Developed by Cisco, Nuance, and Speechworks) に記述された Media Resource Control Protocol (MRCP) がある. MRCP は音声認識器・音声合成器をはじめとする様々な機器のために Cisco Systems, Nuance Communications, Speechworks の 3 社が共同で開発したプロトコルである. MRCP は RTSP とくみあわせて (RTSP のメッセージ本体において) 使用されている. MRCP は SIP や RTSP と同様に HTTP をモデルとしたプロトコルであり,上記のドラフトにおいて要求メッセージのメソッドや応答メッセージのコードなどが規定されている. なお,MRCP に関してはその拡張が 2003 年 10 月に発行されたインターネット・ドラフト draft-burnett-mrcpext-00 (D. Burnett, P. Forgues, C. Galles: MRCP Extensions: Media resource Control Protocol Extensions) において提案されている. また,MRCP によって実現されているような機器を分散的に制御するための要求仕様が 2003 年 6 月に発行されたインターネット・ドラフト draft-ietf-speechsc-reqts-04 (D. Oran: Requirements for Distributed Control of ASR, SI/SV and TTS Resources) にまとめられている.

また,2003 年 6 月に発行されたインターネット・ドラフト draft-ietf-avt-mwpp-midi-rtp-08 (J. Lazzaro: RTP Payload Format for MIDI) においては MIDI における巻き戻しなどの機能を実現するため,MIDI のコマンドを RTSP にのせて使用している.

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

コメント (1)

武内文博:

良くわかった

コメントを投稿

Powered by
Movable Type 3.36