RTSP

RTSP プロトコル#

リアルタイムストリーミングプロトコル（Real Time Streaming Protocol、RTSP）は、エンターテインメントおよび通信システムの使用のために特別に設計されたネットワークアプリケーションプロトコルで、ストリーミングメディアサーバーを制御します。このプロトコルは、端末間のメディアセッションを作成および制御するために使用されます。メディアサーバーのクライアントは、再生、録画、一時停止などの VCR コマンドを発行し、サーバーからクライアント（ビデオオンデマンド）またはクライアントからサーバー（音声録音）へのメディアストリームのリアルタイム制御を容易にします。これは、コロンビア大学、ネットスケープ、RealNetworks 社が提出した IETF RFC 標準の TCP/IP プロトコルスタック内のアプリケーション層プロトコルです。対応する RFC 番号は 2326 で、ここで検索できます RFC Editor

このプロトコルは、IP ネットワークを介してマルチメディアデータを効率的に送信する方法を定義しています。RTSP は、RTP および RTCP の上に位置し、TCP または RTP を使用してデータ転送を完了します。RTSP は、メディアストリームの制御を確立するために使用され、マルチメディアサービスにおいて「ネットワークリモートコントロール」の役割を果たします。時にはRTSP 制御情報とメディアデータストリームを交互に送信することができますが、一般的には RTSP 自体はメディアストリームデータの転送には使用されません。メディアデータの転送は、RTP/RTCP などのプロトコルを介して行われます。

このプロトコルは C/S モデルで使用され、クライアントとサーバー間でリアルタイムストリームセッションを確立および交渉するためのテキストベースのプロトコルです。

プロトコル体系#

基本的な RTSP 操作の流れ：

まず、クライアントはストリームサーバーに接続し、RTSP 記述コマンド（DESCRIBE）を送信します。
ストリームサーバーは SDP 記述を通じてフィードバックを行い、フィードバック情報にはストリームの数、メディアタイプなどの情報が含まれます。
クライアントはその SDP 記述を解析し、セッション内の各ストリームに対して RTSP セットアップコマンド（SETUP）を送信します。RTSP セットアップコマンドは、サーバーにクライアントがメディアデータを受信するためのポートを通知します。ストリーミング接続が確立されると、
クライアントは再生コマンド（PLAY）を送信し、サーバーは UDP 上でメディアストリーム（RTP パケット）をクライアントに送信し始めます。再生中、クライアントはサーバーに対して早送り、巻き戻し、一時停止などのコマンドを送信することもできます。
最後に、クライアントはストリーミングメディアセッションを終了するために終了コマンド（TEARDOWN）を送信できます。

    クライアント->サーバー：DESCRIBE
    サーバー->クライアント：200 OK (SDP)
    クライアント->サーバー：SETUP
    サーバー->クライアント：200 OK
    クライアント->サーバー：PLAY
    サーバー->クライアント：(RTPパケット）

プロトコルの特徴#

拡張性：新しいメソッドやパラメータを RTSP に簡単に追加できます。
解析の容易さ：RTSP は標準の HTTP または MIME 解析器で解析できます。
セキュリティ：RTSP はウェブセキュリティメカニズムを使用します。
転送に依存しない：RTSP は信頼性のないデータグラムプロトコル（UDP）や信頼性のあるデータグラムプロトコル（RDP）を使用できます。アプリケーションレベルの信頼性を実現するには、信頼性のあるストリームプロトコルを使用します。
複数サーバーのサポート：各ストリームは異なるサーバーに配置でき、ユーザー端末は自動的に異なるサーバーと複数の同時制御接続を確立し、メディアの同期はトランスポート層で実行されます。
録画デバイスの制御：プロトコルは録画および再生デバイスを制御できます。
ストリーム制御と会議開始の分離：会議の初期化プロトコルを提供することが求められるか、ユニークな会議識別番号を作成するために使用できます。特別な場合には、SI または H.323 を使用してサーバーを会議に招待できます。
専門的なアプリケーションに適している：SMPTE タイムスタンプを介して、RTSP はフレームレベルの精度をサポートし、リモートデジタル編集を可能にします。
プレゼンテーション記述の中立性：プロトコルは特別なプレゼンテーションやメタファイルを強制せず、使用するフォーマットタイプを送信できます。ただし、プレゼンテーション記述には少なくとも 1 つの RTSP URL を含める必要があります。
プロキシフレンドリー：ここで、RTSP は HTTP の概念を賢く採用し、現在の構造を再利用可能にします。構造にはインターネットコンテンツ選択プラットフォーム（PICS）が含まれます。ほとんどの場合、連続メディアの制御にはサーバーの状態が必要なため、RTSP は HTFP にメソッドを追加するだけではありません。
適切なサーバー制御：ユーザーがストリームを開始した場合、ストリームを停止することもできなければなりません。
転送の調整：実際に連続メディアストリームを処理する前に、ユーザーは転送方法を調整できます。
パフォーマンスの調整：基本的な機能が無効な場合、ユーザーがどの方法が無効であるかを決定するためのクリーンアップメカニズムが必要です。

メッセージ構造#

RTSP URL#

エンドユーザーは、プレーヤーに URL アドレスを入力することでストリーミングメディアサービスの視聴を開始しますが、RTSP プロトコルを使用するモバイルストリーミングオンデマンドの場合、URL の一般的な書き方は次のとおりです：

「rtsp」または「rtspu」で始まる URL リンクは、現在使用されているのが RTSP プロトコルであることを指定します。RTSP URL の構文は次のようになります： rtsp_url = (“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name

host：有効なドメイン名または IP アドレスである必要があります。
port：ポート番号。RTSP プロトコルの場合、デフォルトのポート番号は 554 です。ストリーミングメディアサーバーが提供するポート番号が 554 であることを確認した場合、この項目は省略できます。
abs_path：RTSP サーバー内のメディアストリームリソースの識別子で、次の章の録画リソース命名を参照してください。

RTSP URL は、RTSP サーバーのメディアストリームリソースを識別するために使用され、単一のメディアストリームリソースを識別することも、複数のメディアストリームリソースの集合を識別することもできます。

RTSP メッセージ#

RTSP はテキストベースのプロトコルで、CRLF を行の終了文字として使用します。

RTSP には 2 種類のメッセージがあります：リクエストメッセージとレスポンスメッセージ。リクエストメッセージは、クライアントからサーバーへのリクエストメッセージを指し、レスポンスメッセージはサーバーからクライアントへの応答を指します。RTSP はテキスト指向であるため、メッセージ内の各フィールドは ASCII コードの文字列であり、各フィールドの長さは不確定です。RTSP メッセージは、開始行、ヘッダー行、エンティティボディの 3 つの部分で構成されています。リクエストメッセージでは、開始行はリクエスト行です。

RTSP リクエストメッセージのメソッドには、OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER、SET_PARAMETER があります。

リクエストメッセージ（a request message）は、クライアントからサーバーに発信されることも、サーバーからクライアントに発信されることもあります。リクエストメッセージの構文は次のとおりです：

Request = Request-Line
(general-header|request-header|entity-header)
CRLF
[message-body]

リクエスト行

リクエストメッセージの最初の行の構文は次のとおりです：

Request-Line = Method 空白 Request-URI 空白 RTSP-Version CRLF

メッセージ行に現れる最初の単語が使用されるシグナリングフラグです。現在知られているシグナリングフラグは次のとおりです：

Method = “DESCRIBE” 
        | “ANNOUNCE”
        | “GET_PARAMETER”
        | “OPTIONS”
        | “PAUSE”
        | “PLAY”
        | “RECORD”
        | “REDIRECT”
        | “SETUP”
        | “SET_PARAMETER”
        | “TEARDOWN”

例： DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0

リクエストヘッダーフィールド

メッセージヘッダーには、最初の行の内容に加えて、追加情報を提供するためのいくつかの要求があります。中には必須のものもあり、後でよく使用されるいくつかのフィールドの意味について詳しく説明します。

Request-header = Accept
    |	Accept-Encoding
    |	Accept-Language
    |	Authorization
    |	From
    |	If-Modified-Since
    |	Range
    |	Referer
    |	User-Agent

レスポンスメッセージ

レスポンスメッセージの構文は次のとおりです：

Response = Status-Line 
(general-header |response-header|entity-header) 
CRLF 
[message-body]

ステータス行

レスポンスメッセージの最初の行はステータス行（status-line）で、各要素は空白で区切られています。最後の CRLF を除いて、この行の中間には CR または LF が現れてはなりません。その構文形式は次のとおりです。

Status-Line = RTSP-Version 空白 Status-Code 空白 Reason-Phrase CRLF

ステータスコード（Status-Code）は、受信者が受け取ったリクエストメッセージの実行結果を説明するための 3 桁の整数です。

Status-Code の最初の数字は、この応答メッセージの種類を指定します。合計で 5 種類あります：

1XX：情報 – リクエストが受信され、処理を続行します。
2XX：成功 – リクエストが正常に受信され、解析され、受け入れられました。
3XX：リダイレクション – リクエストを完了するためにさらに操作が必要です。
4XX：クライアントエラー – リクエストメッセージに構文エラーが含まれているか、正常に実行できません。
5XX：サーバーエラー – サーバーの応答が失敗し、正しい有効なリクエストメッセージを処理できません。

問題を処理する際によく遭遇するステータスコードは次のとおりです：

 Status-Code= “200": OK ,
              “400”: Bad Request ,
              “404”: Not Found ,
              “500”: Internal Server Error

レスポンスヘッダーフィールド

レスポンスメッセージのフィールドには、ステータス行に含めることができず、リクエスト者に送信する必要がある追加情報が格納されています。

Response-header = Location
Proxy-Authenticate
Public
Retry-After
Server
Vary
WWW-Authenticate

主要なメソッド#

メソッド	方向	オブジェクト	要求	意味
DESCRIBE	C->S	P S	推奨	プレゼンテーションまたはメディアオブジェクトの記述を確認し、DESCRIBE の応答 - レスポンスはメディア RTSP 初期段階を構成します
ANNOUNCE	C->S S->C	P S	任意	URL で識別されたオブジェクトをサーバーに送信し、逆に ANNOUNCE は接続の記述をリアルタイムで更新します。
GET_PARAMETER	C->S S->C	P S	任意	RUL で指定されたプレゼンテーションとメディアのパラメータ値を確認するリクエスト
OPTIONS	C->S S->C	P S	要求	任意の時点で OPTIONS リクエストを発行できます
PAUSE	C->S	P S	推奨	PAUSE リクエストはストリーム送信の一時中断を引き起こします
PLAY	C->S	P S	要求	PLAY はサーバーに SETUP で指定されたメカニズムでデータの送信を開始するように指示します
RECORD	C->S	P S	任意	このメソッドはプレゼンテーション記述に基づいてメディアデータの記録範囲を初期化します
REDIRECT	S->C	P S	任意	リダイレクトリクエストはクライアントに別のサーバーアドレスに接続するよう通知します
SETUP	C->S	S	要求	URL の SETUP リクエストはストリーミングのための転送メカニズムを指定します
SET_PARAMETER	C->S S->C	P S	任意	プレゼンテーションまたは URL で指定されたストリームのパラメータ値を設定するリクエスト
TEARDOWN	C->S	P S	要求	TEARDOWN リクエストは指定された URL ストリームの送信を停止し、関連リソースを解放します

注：P--- プレゼンテーション、C--- クライアント、S--- サーバー、S（オブジェクトバー）--- ストリーム

シグナリングは、Request-URI で指定された受信者が完了する必要のある操作を指します。シグナリング（The method）は大文字と小文字が区別され、文字「$」で始めることはできず、必ずトークンである必要があります。

RTSP ヘッダーパラメータ#

Accept：クライアントが受け入れることができるメディア記述情報のタイプを指定します。例えば：Accept: application/rtsl, application/sdp;level=2。
Bandwidth：クライアントが利用可能な帯域幅値を記述します。
CSeq：RTSP リクエスト応答ペアのシーケンス番号を指定し、各リクエストまたは応答にこのヘッダーフィールドを含める必要があります。特定のシーケンス番号を含むリクエストメッセージには、同じシーケンス番号の応答メッセージがあります。
Range：時間範囲を指定するために使用され、SMPTE、NTP、またはクロック時間単位を使用できます。
Session：Session ヘッダーフィールドは RTSP セッションを識別します。Session ID は、SETUP の応答でサーバーによって選択され、クライアントが Session ID を取得すると、以降の Session 操作リクエストメッセージには Session ID を含める必要があります。
Transport: Transport ヘッダーフィールドには、クライアントが受け入れることができる転送オプションのリストが含まれ、転送プロトコル、アドレスポート、TTL などが含まれます。サーバー側もこのヘッダーフィールドを介して実際に選択された具体的なオプションを返します。例えば：Transport:RTP/AVP;multicast;ttl=127;mode="PLAY", RTP/AVP;unicast;client_port=1289-1290;mode="PLAY"

簡単な RTSP メッセージの相互作用プロセス#

CはRTSPクライアント、SはRTSPサーバーを示します
第一歩：サーバー側の利用可能なメソッドを照会 
C->S OPTION request  	Sに利用可能なメソッドを問い合わせます
S->C OPTION response 	Sは提供されるすべての利用可能なメソッドをpublicヘッダーに含めて応答します
第二歩：メディア記述情報を取得 
C->S DESCRIBE request  	Sが提供するメディア記述情報を要求します
S->C DESCRIBE response  Sはメディア記述情報、一般的にはSDP情報を応答します
第三歩：RTSPセッションを確立 
C->S SETUP request 	Transportヘッダーフィールドに受け入れ可能な転送オプションを列挙し、Sにセッションを確立するよう要求します
S->C SETUP response SはTransportヘッダーフィールドを介して選択された具体的な転送オプションを返し、確立されたSession IDを返します
第四歩：データの送信を開始するリクエスト
C->S PLAY request 	CはSにデータの送信を開始するよう要求します
S->C PLAY response	Sはそのリクエストに対する情報を応答します
第五歩：データ送信中 
S->C ストリーミングデータを送信 	RTPプロトコルを介してデータを送信します
第六歩：セッションを閉じて終了
C->S TEARDOWN request 	Cはセッションを閉じるよう要求します
S->C TEARDOWN response 	Sはそのリクエストに応答します

上記のプロセスは標準的で友好的な RTSP フローですが、実際の要求では必ずしもこのプロセスに従う必要はありません。第三および第四のステップは必須です！第一のステップでは、サーバーとクライアントが利用可能なメソッドについて合意すれば、OPTIONS リクエストは不要です。第二のステップでは、メディア初期化記述情報を取得する他の手段（例えば HTTP リクエストなど）があれば、RTSP の DESCRIBE リクエストを通じて完了する必要はありません。