1 Introduction (はじめに)

1.1 Purpose (目的)

Real-Time Streaming Protocol (リアルタイムストリーミングプロトコル, RTSP) は, オーディオやビデオなどの連続メディアの単一または複数の時間同期ストリームを確立し制御します。通常, 連続ストリーム自体を配信しませんが, 制御ストリームとの連続メディアストリームのインターリーブは可能です (セクション 10.12 参照)。言い換えれば, RTSP はマルチメディアサーバーの "ネットワークリモートコントロール" として機能します。

制御対象のストリームセットは, プレゼンテーション記述 (presentation description) によって定義されます。このメモは, プレゼンテーション記述の形式を定義しません。

RTSP 接続の概念はありません。代わりに, サーバーは識別子によってラベル付けされたセッションを維持します。RTSP セッションは, TCP 接続などのトランスポートレベル接続に決して結び付けられません。RTSP セッション中, RTSP クライアントは, RTSP リクエストを発行するために, サーバーへの多数の信頼できるトランスポート接続を開閉できます。または, UDP などの非接続型トランスポートプロトコルを使用することもできます。

RTSP によって制御されるストリームは RTP [1] を使用できますが, RTSP の動作は連続メディアを伝送するために使用されるトランスポートメカニズムに依存しません。このプロトコルは, 構文と動作において意図的に HTTP/1.1 [2] と類似しているため, HTTP の拡張メカニズムをほとんどの場合 RTSP にも追加できます。ただし, RTSP は HTTP といくつかの重要な点で異なります:

RTSP は多数の新しいメソッドを導入し, 異なるプロトコル識別子を持っています。* RTSP サーバーは, HTTP のステートレスな性質とは対照的に, ほとんどすべての場合にデフォルトで状態を維持する必要があります。* RTSP サーバーとクライアントの両方がリクエストを発行できます。* データは異なるプロトコルによって帯域外で伝送されます。(これには例外があります。) * RTSP は, 現在の HTML 国際化作業 [3] と一致して, ISO 8859-1 ではなく ISO 10646 (UTF-8) を使用するように定義されています。* Request-URI は常に絶対 URI を含みます。歴史的な失敗との後方互換性のため, HTTP/1.1 [2] はリクエストで絶対パスのみを運び, ホスト名を別のヘッダーフィールドに入れます。

これにより, "バーチャルホスティング" が容易になります。1つの IP アドレスを持つ単一のホストが複数のドキュメントツリーをホストできます。

このプロトコルは次の操作をサポートします:

メディアサーバーからのメディアの取得: クライアントは HTTP または他の方法でプレゼンテーション記述を要求できます。プレゼンテーションがマルチキャストされている場合, プレゼンテーション記述には連続メディアに使用されるマルチキャストアドレスとポートが含まれます。プレゼンテーションがユニキャストを介してクライアントのみに送信される場合, セキュリティ上の理由からクライアントが宛先を提供します。

会議へのメディアサーバーの招待: メディアサーバーは, プレゼンテーションにメディアを再生するか, プレゼンテーション内のメディアの全部または一部を記録するために, 既存の会議に参加するように "招待" できます。このモードは分散教育アプリケーションに役立ちます。会議の複数の当事者が交代で "リモコンボタンを押す" ことができます。

既存のプレゼンテーションへのメディアの追加: 特にライブプレゼンテーションの場合, サーバーがクライアントに利用可能になった追加のメディアについて通知できると便利です。

RTSP リクエストは, HTTP/1.1 [2] のようにプロキシ, トンネル, キャッシュによって処理できます。

1.2 Requirements (要件)

このドキュメントのキーワード "MUST" (しなければならない), "MUST NOT" (してはならない), "REQUIRED" (必要), "SHALL" (するものとする), "SHALL NOT" (しないものとする), "SHOULD" (すべきである), "SHOULD NOT" (すべきではない), "RECOMMENDED" (推奨), "MAY" (してもよい), "OPTIONAL" (オプション) は, RFC 2119 [4] に記載されているように解釈されるものとします。

1.3 Terminology (用語)

一部の用語は HTTP/1.1 [2] から採用されています。ここにリストされていない用語は HTTP/1.1 で定義されているとおりです。

Aggregate control (集約制御): サーバーによる単一のタイムラインを使用した複数のストリームの制御。オーディオ/ビデオフィードの場合, これはクライアントが単一の再生または一時停止メッセージを発行してオーディオとビデオの両方のフィードを制御できることを意味します。

Conference (会議): マルチパーティ, マルチメディアプレゼンテーション。"multi" (マルチ) は1以上を意味します。

Client (クライアント): クライアントはメディアサーバーから連続メディアデータを要求します。

Connection (接続): 通信目的で2つのプログラム間に確立されたトランスポート層仮想回路。

Container file (コンテナファイル): 複数のメディアストリームを含む可能性のあるファイル。これらは一緒に再生されるとプレゼンテーションを構成することがよくあります。RTSP サーバーはこれらのファイルに集約制御を提供できますが, コンテナファイルの概念はプロトコルに組み込まれていません。

Continuous media (連続メディア): ソースとシンクの間にタイミング関係があるデータ。つまり, シンクはソースに存在したタイミング関係を再現する必要があります。連続メディアの最も一般的な例は, オーディオとモーションビデオです。連続メディアは, ソースとシンクの間に "密接な" タイミング関係があるリアルタイム (インタラクティブ) の場合と, 関係がそれほど厳密ではないストリーミング (再生) の場合があります。

Entity (エンティティ): リクエストまたはレスポンスのペイロードとして転送される情報。エンティティは, セクション 8 で説明されているように, エンティティヘッダーフィールドの形式のメタ情報とエンティティボディの形式のコンテンツで構成されます。

Media initialization (メディア初期化): データタイプ/コーデック固有の初期化。これには, クロックレート, カラーテーブルなどが含まれます。クライアントがメディアストリームを再生するために必要なトランスポートに依存しない情報は, ストリームセットアップのメディア初期化フェーズで発生します。

Media parameter (メディアパラメータ): ストリーム再生の前または再生中に変更できるメディアタイプ固有のパラメータ。

Media server (メディアサーバー): 1つ以上のメディアストリームに再生または記録サービスを提供するサーバー。プレゼンテーション内の異なるメディアストリームは, 異なるメディアサーバーから発信される場合があります。メディアサーバーは, プレゼンテーションが呼び出される Web サーバーと同じホストまたは異なるホストに存在できます。

Media server indirection (メディアサーバーリダイレクション): メディアクライアントを別のメディアサーバーにリダイレクトすること。

(Media) stream (メディアストリーム): 単一のメディアインスタンス。例えば, オーディオストリームまたはビデオストリーム, および単一のホワイトボードまたは共有アプリケーショングループ。RTP を使用する場合, ストリームは RTP セッション内のソースによって作成されたすべての RTP および RTCP パケットで構成されます。これは DSM-CC ストリームの定義と同等です ([5])。

Message (メッセージ): RTSP 通信の基本単位。セクション 15 で定義された構文に一致する構造化されたオクテットシーケンスで構成され, 接続または非接続プロトコルを介して送信されます。

Participant (参加者): 会議のメンバー。参加者はマシンである場合があります。例えば, メディア記録または再生サーバー。

Presentation (プレゼンテーション): 以下に定義するプレゼンテーション記述を使用して, 完全なメディアフィードとしてクライアントに提示される1つ以上のストリームのセット。RTSP コンテキストのほとんどの場合, これはこれらのストリームの集約制御を意味しますが, 必ずしもそうである必要はありません。

Presentation description (プレゼンテーション記述): プレゼンテーション記述には, エンコーディングのセット, ネットワークアドレス, コンテンツに関する情報など, プレゼンテーション内の1つ以上のメディアストリームに関する情報が含まれます。SDP (RFC 2327 [6]) などの他の IETF プロトコルは, ライブプレゼンテーションに "session" (セッション) という用語を使用します。プレゼンテーション記述は, セッション記述形式 SDP を含むがこれに限定されない, いくつかの異なる形式をとることができます。

Response (レスポンス): RTSP レスポンス。HTTP レスポンスを意味する場合は, 明示的に示されます。

Request (リクエスト): RTSP リクエスト。HTTP リクエストを意味する場合は, 明示的に示されます。

RTSP session (RTSP セッション): 完全な RTSP "トランザクション"。例えば, 映画の視聴。セッションは通常, クライアントが連続メディアストリームのトランスポートメカニズムをセットアップし (SETUP), PLAY または RECORD でストリームを開始し, TEARDOWN でストリームを閉じることで構成されます。

Transport initialization (トランスポート初期化): クライアントとサーバー間のトランスポート情報 (ポート番号, トランスポートプロトコルなど) のネゴシエーション。

1.4 Protocol Properties (プロトコルの特性)

RTSP には次の特性があります:

Extendable (拡張可能): 新しいメソッドとパラメータを RTSP に簡単に追加できます。

Easy to parse (解析が容易): RTSP は標準の HTTP または MIME パーサーで解析できます。

Secure (セキュア): RTSP は Web セキュリティメカニズムを再利用します。基本認証 (RFC 2068 [2, セクション 11.1]) やダイジェスト認証 (RFC 2069 [8]) などのすべての HTTP 認証メカニズムが直接適用されます。トランスポート層またはネットワーク層のセキュリティメカニズムも再利用できます。

Transport-independent (トランスポート独立): RTSP は, アプリケーションレベルの信頼性を実装するため, 信頼性の低いデータグラムプロトコル (UDP) (RFC 768 [9]), 信頼できるデータグラムプロトコル (RDP, RFC 1151, 広く使用されていない [10]), または TCP (RFC 793 [11]) などの信頼できるストリームプロトコルのいずれかを使用できます。

Multi-server capable (マルチサーバー対応): プレゼンテーション内の各メディアストリームは異なるサーバーに存在できます。クライアントは異なるメディアサーバーとの複数の同時制御セッションを自動的に確立します。メディア同期はトランスポートレベルで実行されます。

Control of recording devices (記録デバイスの制御): このプロトコルは, 記録デバイスと再生デバイスの両方, および2つのモード間を切り替えることができるデバイス ("VCR") を制御できます。

Separation of stream control and conference initiation (ストリーム制御と会議開始の分離): ストリーム制御は, 会議にメディアサーバーを招待することとは切り離されています。唯一の要件は, 会議開始プロトコルが一意の会議識別子を提供するか, 作成するために使用できることです。特に, SIP [12] または H.323 [13] を使用してサーバーを会議に招待できます。

Suitable for professional applications (プロフェッショナルアプリケーションに適している): RTSP は SMPTE タイムスタンプを通じてフレームレベルの精度をサポートし, リモートデジタル編集を可能にします。

Presentation description neutral (プレゼンテーション記述に中立): このプロトコルは特定のプレゼンテーション記述またはメタファイル形式を課さず, 使用する形式のタイプを伝えることができます。ただし, プレゼンテーション記述には少なくとも1つの RTSP URI を含める必要があります。

Proxy and firewall friendly (プロキシとファイアウォールフレンドリー): このプロトコルは, アプリケーションレイヤーおよびトランスポートレイヤー (SOCKS [14]) ファイアウォールの両方で容易に処理されるべきです。ファイアウォールは, UDP メディアストリーム用の "穴" を開くために SETUP メソッドを理解する必要がある場合があります。

HTTP-friendly (HTTP フレンドリー): 合理的な場合, RTSP は HTTP の概念を再利用するため, 既存のインフラストラクチャを再利用できます。このインフラストラクチャには, コンテンツにラベルを関連付けるための PICS (Platform for Internet Content Selection [15,16]) が含まれます。ただし, ほとんどの場合連続メディアの制御にはサーバーの状態が必要なため, RTSP は HTTP にメソッドを追加するだけではありません。

Appropriate server control (適切なサーバー制御): クライアントがストリームを開始できる場合, ストリームを停止できる必要があります。サーバーは, クライアントがストリームを停止できないような方法でクライアントへのストリーミングを開始すべきではありません。

Transport negotiation (トランスポートネゴシエーション): クライアントは, 実際に連続メディアストリームを処理する必要が生じる前に, トランスポート方法をネゴシエートできます。

Capability negotiation (機能ネゴシエーション): 基本機能が無効になっている場合, クライアントが実装されないメソッドを決定するためのクリーンなメカニズムが必要です。これにより, クライアントは適切なユーザーインターフェースを提示できます。例えば, シークが許可されていない場合, ユーザーインターフェースはスライディング位置インジケーターの移動を禁止できる必要があります。

RTSP の初期の要件はマルチクライアント機能でした。ただし, より良いアプローチは, プロトコルをマルチクライアントシナリオに容易に拡張できるようにすることであると判断されました。ストリーム識別子は複数の制御ストリームで使用できるため, "リモコンを渡す" ことが可能になります。このプロトコルは, 複数のクライアントがアクセスをネゴシエートする方法には対処しません。これは "社会的プロトコル" または他のフロア制御メカニズムに任されています。

1.5 Extending RTSP (RTSP の拡張)

すべてのメディアサーバーが同じ機能を持っているわけではないため, メディアサーバーは必然的に異なるリクエストセットをサポートします。例えば:

サーバーは再生のみが可能な場合があるため, RECORD リクエストをサポートする必要はありません。* サーバーがライブイベントのみをサポートする場合, シーク (絶対位置指定) ができない場合があります。* 一部のサーバーはストリームパラメータの設定をサポートしていないため, GET_PARAMETER と SET_PARAMETER をサポートしません。

サーバーはセクション 12 で説明されているすべてのヘッダーフィールドを実装すべきです。

プレゼンテーション記述の作成者は, サーバーに不可能なことを要求しないようにする責任があります。この状況は HTTP/1.1 [2] と類似しており, [H19.6] で説明されているメソッドはすべてのサーバーでサポートされる可能性は低いです。

RTSP は3つの方法で拡張できます。ここでは, サポートされる変更の大きさの順にリストされています:

既存のメソッドは, 受信者がこれらのパラメータを安全に無視できる限り, 新しいパラメータで拡張できます。(これは HTML タグに新しいパラメータを追加することに相当します。) メソッド拡張がサポートされていない場合にクライアントが否定応答を必要とする場合, Require: フィールドに拡張に対応するタグを追加できます (セクション 12.32 参照)。* 新しいメソッドを追加できます。メッセージの受信者がリクエストを理解しない場合, エラーコード 501 (Not implemented) で応答し, 送信者はこのメソッドを再度使用しないでください。クライアントは OPTIONS メソッドを使用して, サーバーがサポートするメソッドを照会することもできます。サーバーは Public レスポンスヘッダーを使用してサポートするメソッドをリストすべきです。* プロトコルの新しいバージョンを定義でき, ほぼすべての側面 (プロトコルバージョン番号の位置を除く) を変更できます。

1.6 Overall Operation (全体的な動作)

各プレゼンテーションとメディアストリームは RTSP URL で識別できます。全体的なプレゼンテーションとプレゼンテーションを構成するメディアのプロパティは, プレゼンテーション記述ファイルによって定義されます。その形式はこの仕様の範囲外です。プレゼンテーション記述ファイルは, クライアントが HTTP または電子メールなどの他の手段を使用して取得でき, 必ずしもメディアサーバーに保存される必要はありません。

この仕様の目的上, プレゼンテーション記述は1つ以上のプレゼンテーションを記述し, それぞれが共通の時間軸を維持すると想定されています。説明を簡単にし, 一般性を失うことなく, プレゼンテーション記述にはそのようなプレゼンテーションが1つだけ含まれていると想定されます。プレゼンテーションには複数のメディアストリームが含まれる場合があります。

プレゼンテーション記述ファイルには, エンコーディング, 言語, およびクライアントが最も適切なメディアの組み合わせを選択できるようにする他のパラメータを含む, プレゼンテーションを構成するメディアストリームの説明が含まれています。このプレゼンテーション記述では, RTSP によって個別に制御可能な各メディアストリームは RTSP URL によって識別され, その特定のメディアストリームを処理するメディアサーバーを指し, そのサーバーに保存されているストリームを名前で指定します。複数のメディアストリームは異なるサーバーに配置できます。例えば, オーディオとビデオのストリームは負荷分散のためにサーバー間で分割できます。この記述は, サーバーが対応できるトランスポート方法も列挙します。

メディアパラメータに加えて, ネットワーク宛先アドレスとポートを決定する必要があります。いくつかの動作モードを区別できます:

Unicast (ユニキャスト): メディアは RTSP リクエストのソースに送信され, ポート番号はクライアントによって選択されます。または, メディアは RTSP と同じ信頼できるストリームで送信されます。

Multicast, server chooses address (マルチキャスト, サーバーがアドレスを選択): メディアサーバーがマルチキャストアドレスとポートを選択します。これは, ライブまたはニアメディアオンデマンド送信の典型的なケースです。

Multicast, client chooses address (マルチキャスト, クライアントがアドレスを選択): サーバーが既存のマルチキャスト会議に参加する場合, マルチキャストアドレス, ポート, 暗号化キーは会議記述によって与えられ, この仕様の範囲外の手段によって確立されます。

1.7 RTSP States (RTSP 状態)

RTSP は, 制御チャネルとは独立した別のプロトコルによって送信される可能性のあるストリームを制御します。例えば, RTSP 制御は TCP 接続で発生する可能性がありますが, データは UDP 経由で流れます。したがって, メディアサーバーが RTSP リクエストを受信しなくても, データ配信は継続されます。また, その存続期間中, 単一のメディアストリームは, 異なる TCP 接続で順次発行される RTSP リクエストによって制御される場合があります。したがって, サーバーは RTSP リクエストをストリームと関連付けることができるように "セッション状態" を維持する必要があります。状態遷移は付録 A で説明されています。

RTSP の多くのメソッドは状態に寄与しません。ただし, 次のメソッドは, サーバー上のストリームリソースの割り当てと使用の定義において中心的な役割を果たします: SETUP, PLAY, RECORD, PAUSE, TEARDOWN。

SETUP: サーバーにストリームのリソースを割り当てさせ, RTSP セッションを開始します。

PLAY および RECORD: SETUP を介して割り当てられたストリームでデータ送信を開始します。

PAUSE: サーバーリソースを解放せずにストリームを一時的に停止します。

TEARDOWN: ストリームに関連付けられたリソースを解放します。RTSP セッションはサーバー上に存在しなくなります。

状態に寄与する RTSP メソッドは, 操作されている RTSP セッションを識別するために Session ヘッダーフィールド (セクション 12.37) を使用します。サーバーは SETUP リクエスト (セクション 10.4) への応答としてセッション識別子を生成します。

1.8 Relationship with Other Protocols (他のプロトコルとの関係)

RTSP は HTTP と機能的にいくつかの重複があります。ストリーミングコンテンツとの最初の接触は多くの場合 Web ページを通じて行われるため, HTTP と相互作用する場合もあります。現在のプロトコル仕様は, Web サーバーと RTSP を実装するメディアサーバーの間の異なるハンドオフポイントを許可することを目的としています。例えば, プレゼンテーション記述は HTTP または RTSP を使用して取得でき, Web ブラウザベースのシナリオでのラウンドトリップを削減しますが, HTTP にまったく依存しないスタンドアロン RTSP サーバーとクライアントも可能にします。

ただし, RTSP は, データ配信が異なるプロトコルで帯域外で行われるという点で HTTP と根本的に異なります。HTTP は, クライアントがリクエストを発行し, サーバーが応答する非対称プロトコルです。RTSP では, メディアクライアントとメディアサーバーの両方がリクエストを発行できます。RTSP リクエストもステートレスではありません。リクエストが確認された後も長期間パラメータを設定し, メディアストリームを制御し続ける場合があります。

HTTP 機能の再利用には, 少なくとも2つの領域, すなわちセキュリティとプロキシにおいて利点があります。要件は非常に似ているため, キャッシュ, プロキシ, 認証に関する HTTP の作業を採用できる能力は価値があります。

ほとんどのリアルタイムメディアは RTP をトランスポートプロトコルとして使用しますが, RTSP は RTP に結び付けられていません。

RTSP は, 複数のメディアストリームを含むプレゼンテーションの静的および時間的プロパティの両方を表現できるプレゼンテーション記述形式の存在を前提としています。