リアルタイムストリーミングプロトコル

リアルタイム ストリーミング プロトコル( RTSP )は、適切なトランスポート プロトコルを介してマルチメディアトランスポート ストリーム (インタラクティブ メディア、ビデオ、オーディオなど)を多重化およびパケット化するために設計されたアプリケーション レベルのネットワークプロトコルです。RTSP は、エンターテイメント システムや通信システムでストリーミング メディアサーバーを制御するために使用されます。このプロトコルは、エンドポイント間のメディア セッションを確立および制御するために使用されます。メディア サーバーのクライアントは、再生、録音、一時停止などのコマンドを発行して、サーバーからクライアント (ビデオ オン デマンド) またはクライアントからサーバー (音声録音) へのメディア ストリーミングのリアルタイム制御を容易にします。

RTSPは、 RealNetworks、Netscape ^[1]、コロンビア大学によって開発されました。^[2]最初のドラフトは、1996年10月にNetscapeとProgressive NetworksによってIETFに提出され、その後、コロンビア大学のHenning Schulzrinneが1996年12月に「RTSP՚」（「RTSPプライム」）を提出しました。^{[3] [4] 2つのドラフトは、}インターネット技術タスクフォース（IETF）のマルチパーティマルチメディアセッション制御ワーキンググループ（MMUSIC WG）によって標準化のために統合され、ワー​​キンググループによってさらにドラフトが公開されました。^{[5] [6] RTSPの}提案標準は、1998年にRFC 2326として公開されました。^[7] RTSP 2.0は、RTSP 1.0の代替として2016年にRFC 7826として公開されました。 RTSP 2.0はRTSP 1.0をベースにしていますが、基本的なバージョンネゴシエーションメカニズム以外は下位互換性がなく、提案標準のままです。^[8]

ストリーミング データの送信自体は RTSP のタスクではありません。ほとんどの RTSP サーバーは、メディア ストリームの配信にリアルタイム トランスポート プロトコル(RTP) とリアルタイム コントロール プロトコル(RTCP) を組み合わせて使用​​します。ただし、ベンダーによっては独自のトランスポート プロトコルを実装しているところもあります。たとえば、 RealNetworksの RTSP サーバー ソフトウェアは、RealNetworks 独自のReal Data Transport (RDT) も使用していました。

RTSP はHTTPといくつかの点で似ていますが、マルチメディアの再生を制御するのに役立つ制御シーケンスを定義します。HTTP はステートレスですが、RTSP にはステートがあります。同時セッションを追跡する必要がある場合は、識別子が使用されます。HTTP と同様に、RTSP はエンドツーエンドの接続を維持するために TCP を使用し、ほとんどの RTSP 制御メッセージはクライアントからサーバーに送信されますが、一部のコマンドは逆方向 (サーバーからクライアントへ) に送信されます。

ここでは基本的なRTSP要求を紹介する。OPTIONS要求のようないくつかの典型的なHTTP要求も利用可能である。デフォルトのトランスポート層ポート番号はTCPとUDPの両方で554 ^[7]であり、後者は制御要求にはほとんど使用されない。

OPTIONS リクエストは、サーバーが受け入れるリクエスト タイプを返します。

C->S: オプション rtsp://example.com/media.mp4 RTSP/1.0
       CSeq: 1
       必要条件: 暗黙の再生
       プロキシ要件: gzip 形式のメッセージ

S->C: RTSP/1.0 200 OK
       CSeq: 1
       公開: 説明、セットアップ、分解、再生、一時停止

DESCRIBE 要求には、RTSP URL (rtsp://...) と、処理できる応答データのタイプが含まれます。この応答には、通常、セッション記述プロトコル(SDP) 形式のプレゼンテーション記述が含まれます。プレゼンテーション記述には、集約 URL で制御されるメディア ストリームがリストされます。通常、オーディオ ストリームとビデオ ストリームにはそれぞれ 1 つのメディア ストリームがあります。メディア ストリーム URL は、SDP 制御フィールドから直接取得されるか、集約 URL に SDP 制御フィールドを追加することによって取得されます。

C->S: rtsp://example.com/media.mp4 RTSP/1.0 を記述します
      CSeq: 2

S->C: RTSP/1.0 200 OK
      CSeq: 2
      コンテンツベース: rtsp://example.com/media.mp4
      コンテンツタイプ: application/sdp
      コンテンツの長さ: 460

      m=ビデオ 0 RTP/AVP 96
      a=コントロール:ストリームID=0
      a=範囲:npt=0-7.741000
      a=長さ:npt=7.741000
      a=rtpmap:96 MP4V-ES/5544
      a=mimetype:文字列;"ビデオ/MP4V-ES"
      a=平均ビットレート:整数;304018
      a=StreamName:string;"ヒント付きビデオトラック"
      m=オーディオ 0 RTP/AVP 97
      a=コントロール:ストリームID=1
      a=範囲:npt=0-7.712000
      a=長さ:npt=7.712000
      a=rtpmap:97 mpeg4-ジェネリック/32000/2
      a=mimetype:string;"audio/mpeg4-generic"
      a=平均ビットレート:整数;65790
      a=StreamName:string;"ヒント付きオーディオトラック"

SETUP 要求は、単一のメディア ストリームをどのように転送するかを指定します。これは、PLAY 要求を送信する前に行う必要があります。要求には、メディア ストリームの URL とトランスポート指定子が含まれます。この指定子には通常、RTPデータ (オーディオまたはビデオ) を受信するためのローカル ポートと、RTCPデータ (メタ情報) 用の別のポートが含まれます。サーバーの応答では通常、選択されたパラメータを確認し、サーバーが選択したポートなどの不足している部分を入力します。集約再生要求を送信する前に、各メディア ストリームを SETUP を使用して構成する必要があります。

C->S: セットアップ rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
      CSeq: 3
      トランスポート: RTP/AVP;ユニキャスト;client_port=8000-8001

S->C: RTSP/1.0 200 OK
      CSeq: 3
      トランスポート: RTP/AVP;ユニキャスト;クライアントポート=8000-8001;サーバーポート=9000-9001;ssrc=1234ABCD
      セッション: 12345678



C->S: セットアップ rtsp://example.com/media.mp4/streamid=1 RTSP/1.0
      CSeq: 3
      トランスポート: RTP/AVP;ユニキャスト;client_port=8002-8003
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 3
      トランスポート: RTP/AVP;ユニキャスト;クライアントポート=8002-8003;サーバーポート=9002-9003;ssrc=1234ABCD
      セッション: 12345678

PLAY 要求により、1 つまたはすべてのメディア ストリームが再生されます。複数の PLAY 要求を送信することで、再生要求を積み重ねることができます。URL は、集約 URL (すべてのメディア ストリームを再生する場合) または単一のメディア ストリーム URL (そのストリームのみを再生する場合) にすることができます。範囲を指定できます。範囲が指定されていない場合、ストリームは最初から最後まで再生されます。または、ストリームが一時停止されている場合は、一時停止した時点から再開されます。

C->S: rtsp://example.com/media.mp4 RTSP/1.0 を再生
      CSeq: 4
      範囲: npt=5-20
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      セッション: 12345678
      RTP 情報: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE 要求は、1 つまたはすべてのメディア ストリームを一時的に停止し、後で PLAY 要求で再開できるようにします。要求には、集約またはメディア ストリームの URL が含まれます。PAUSE 要求の範囲パラメータは、一時停止するタイミングを指定します。範囲パラメータを省略すると、一時停止は直ちに無期限に発生します。

C->S: 一時停止 rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 5
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 5
      セッション: 12345678

このメソッドは、プレゼンテーション記述に従って、メディア データの範囲の記録を開始します。タイムスタンプは、開始時刻と終了時刻 (UTC) を反映します。時間範囲が指定されていない場合は、プレゼンテーション記述で指定された開始時刻または終了時刻を使用します。セッションがすでに開始されている場合は、すぐに記録を開始します。サーバーは、記録されたデータを要求 URI の下に格納するか、別の URI の下に格納するかを決定します。サーバーが要求 URI を使用しない場合、応答は 201 になり、要求の状態を記述して新しいリソースを参照するエンティティと、Location ヘッダーが含まれます。

C->S: レコード rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 6
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 6
      セッション: 12345678

ANNOUNCE メソッドには 2 つの目的があります。

ANNOUNCE は、クライアントからサーバーに送信されると、リクエスト URL によって識別されるプレゼンテーションまたはメディア オブジェクトの説明をサーバーに投稿します。ANNOUNCE は、サーバーからクライアントに送信されると、セッションの説明をリアルタイムで更新します。新しいメディア ストリームがプレゼンテーションに追加された場合 (ライブ プレゼンテーション中など)、コンポーネントを削除できるように、追加コンポーネントだけでなく、プレゼンテーションの説明全体を再度送信する必要があります。

C->S: アナウンス rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 7
      日付: 1997年1月23日 15:35:06 GMT
      セッション: 12345678
      コンテンツタイプ: application/sdp
      コンテンツの長さ: 332

      0 です
      o=mhandley 2890844526 2890845468 IP4 126.16.64.4 内
      s=SDPセミナー
      i=セッション記述プロトコルに関するセミナー
      u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
      e=mjh@isi.edu (マーク・ハンドリー)
      c=IN IP4 224.2.17.12/127
      2873397496 2873404696 2873404696 28733974 ...397496 28733
      a=受信のみ
      m=オーディオ 3456 RTP/AVP 0
      m=ビデオ 2232 RTP/AVP 31

S->C: RTSP/1.0 200 OK
      CSeq: 7

TEARDOWN リクエストはセッションを終了するために使用されます。すべてのメディア ストリームを停止し、サーバー上のセッション関連データをすべて解放します。

C->S: ティアダウン rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 8
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 8

GET_PARAMETER 要求は、URI で指定されたプレゼンテーションまたはストリームのパラメータの値を取得します。応答とレスポンスの内容は実装に任されています。エンティティ本体のない GET_PARAMETER は、クライアントまたはサーバーの稼働状態 ("ping") をテストするために使用できます。

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 9
      コンテンツタイプ: テキスト/パラメータ
      セッション: 12345678
      コンテンツの長さ: 15

      受信したパケット
      ジッター

C->S: RTSP/1.0 200 OK
      CSeq: 9
      コンテンツの長さ: 46
      コンテンツタイプ: テキスト/パラメータ

      受信パケット数: 10
      ジッター: 0.3838

このメソッドは、URI で指定されたプレゼンテーションまたはストリームのパラメータの値を設定するよう要求します。

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 10
      コンテンツの長さ: 20
      コンテンツタイプ: テキスト/パラメータ

      barparam: バースタッフ

S->C: RTSP/1.0 451 無効なパラメータ
      CSeq: 10
      コンテンツの長さ: 10
      コンテンツタイプ: テキスト/パラメータ

      バーパラム

REDIRECT 要求は、クライアントに別のサーバー ロケーションに接続する必要があることを通知します。この要求には必須ヘッダー Location が含まれており、クライアントがその URL に対して要求を発行する必要があることを示しています。また、リダイレクトがいつ有効になるかを示すパラメータ Range が含まれている場合もあります。クライアントがこの URI に対してメディアの送受信を継続する場合、クライアントは現在のセッションに対して TEARDOWN 要求を発行し、指定されたホストで新しいセッションに対して SETUP 要求を発行する必要があります。

S->C: リダイレクト rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 11
      場所: rtsp://bigserver.com:8001
      範囲: clock=19960213T143205Z-

特定のファイアウォール設計やその他の状況では、サーバーが RTSP メソッドとストリーム データをインターリーブしなければならない場合があります。このインターリーブは、クライアントとサーバーの動作を複雑にし、追加のオーバーヘッドを課すため、必要な場合を除いて通常は避けてください。インターリーブされたバイナリ データは、RTSP が TCP 上で伝送される場合にのみ使用してください。RTP パケットなどのストリーム データは、ASCII ドル記号 (16 進数で 24) でカプセル化され、その後に 1 バイトのチャネル識別子が続き、その後にネットワーク バイト順の 2 バイトのバイナリ整数としてカプセル化されたバイナリ データの長さが続きます。ストリーム データは、CRLF なしですぐに続きますが、上位層プロトコル ヘッダーが含まれます。各 $ ブロックには、1 つの上位層プロトコル データ ユニット (つまり、1 つの RTP パケット) が含まれます。

C->S: セットアップ rtsp://example.com/media.mp4 RTSP/1.0
      CSeq: 3
      トランスポート: RTP/AVP/TCP;インターリーブ=0-1

S->C: RTSP/1.0 200 OK
      CSeq: 3
      日付: 1997 年 6 月 5 日 18:57:18 GMT
      トランスポート: RTP/AVP/TCP;インターリーブ=0-1
      セッション: 12345678

C->S: rtsp://example.com/media.mp4 RTSP/1.0 を再生
      CSeq: 4
      セッション: 12345678

S->C: RTSP/1.0 200 OK
      CSeq: 4
      セッション: 12345678
      日付: 1997 年 6 月 5 日 18:59:15 GMT
      RTP 情報: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234

S->C: $\000{2 バイト長}{"長さ" バイトのデータ、RTP ヘッダー付き}
S->C: $\000{2 バイト長}{"長さ" バイトのデータ、RTP ヘッダー付き}
S->C: $\001{2 バイト長}{"長さ" バイトの RTCP パケット}

RTSP over HTTPは、1999年にAppleによって定義されました^[9]と[1]。RTPビデオとオーディオのデータをRTSPコマンド接続（RFC2326で定義）にインターリーブし、RTSPコマンド接続をHTTP接続のペア（1つは長時間実行されるGET接続、もう1つは長時間実行されるPOST接続）を介して送信します。

この方法はONVIF IP カメラ標準でも使用されており、HTTPS と組み合わせて安全で暗号化されたビデオとオーディオを実現できます。

RTSP コマンド メッセージと RTP ビデオおよびオーディオ データを暗号化する方法はいくつかあります。

RTSP 2.0 (RFC7826) では、暗号化の方法がいくつか定義され、新しい rtsps:// URL が導入されており、その多くが RFC2326 RTSP 1.0 クライアントおよびサーバーに組み込まれています。

• RTSPS URL (rtsps:// URL を使用) - この方法では、TLSソケット (デフォルトはポート 322) を使用して、RTSP クライアントと RTSP サーバー間の暗号化された接続を確立します。
  ビデオとオーディオは、次の 2 つの方法のいずれかで送信できます 。
  • TCPビデオ/オーディオ- RTPビデオとオーディオは、すでに暗号化されたTLS接続を介してRTSPコマンドとインターリーブされて送信されます。
  • UDP およびマルチキャスト UDP ビデオ/オーディオ- RTP ビデオとオーディオは、セキュア RTP (SRTP)プロトコルを使用して暗号化され、RTSPS TLS接続と並行して送信されます。

• RTSP over HTTPS - この方法では、RTP ビデオおよびオーディオ データを RTSP コマンド接続 (RFC2326 で定義) にインターリーブし、暗号化された HTTPS 接続のペアを介して RTSP コマンド接続を送信します。デフォルトではポート 443 を使用します。

IANAは、rtsps:// URLプレフィックスとポート322をRTSPS用に予約しています。^[10] 2024年9月現在、RTSP over HTTPSはいくつかのONVIF IPカメラに実装されており、RTSPS（rtsps:// URLを使用）はAxisおよびBosch CCTVカメラ、^[11] FFmpeg、GStreamer、MediaMTX ^[12]、SharpRTSPによって実装されています。^[13]

RTPとRTCPを使用したRTSPはレート適応の実装を可能にする。^[14]

• Darwin Streaming Server : Apple が管理する QuickTime Streaming Server のオープンソース バージョン。
• GStreamerベースの RTSP サーバーおよびクライアント。
• Helix DNA Server : RealNetworksのストリーミング サーバー。オープン ソースと独自のバージョンの両方があります。
• Helix Universal Server : RTSP、RTMP、iOS、Silverlight、HTTP ストリーミング メディア クライアント向けのRealNetworks商用ストリーミング サーバー
• LIVE555 liveMedia / openRTSP : VLCやmplayerなどの有名なクライアントで使用されるオープンソースのC++サーバーおよびクライアント ライブラリ。
• Motion: Linux 用の無料 CCTV ソフトウェア アプリケーション。
• Nimble Streamer は、 TCP インターリーブ再生出力による RTSP プルおよびアナウンス入力をサポートします。
• OvenMediaEngine は、 RTSP プッシュ入力をサポートするオープンソースの低遅延ストリーミング サーバーです。
• pvServer : 以前は PacketVideo Streaming Server と呼ばれていた、Alcatel-Lucent のストリーミング サーバー製品です。
• QuickTime ストリーミング サーバー: Mac OS X Server に同梱されている Apple のクローズド ソース ストリーミング サーバー。
• VideoLAN : オープンソースのメディアプレーヤーおよびストリーミング サーバー。
• Windows Media Services : 以前はWindows Serverに含まれていた、Windows Media 拡張機能で変更された RTSP を使用するMicrosoft ストリーミング サーバー
• Wowza ストリーミング エンジン: RTSP/RTP、 RTMP、MPEG-TS、ICY、HTTP ( HTTP ライブ ストリーミング、HTTP ダイナミック ストリーミング、スムーズ ストリーミング、MPEG-DASH )、WebRTC用のマルチフォーマット ストリーミング サーバー
• YouTubeは2007年6月にこのプロトコルを通じてビデオを配信するモバイルウェブフロントエンドを実装しました。 ^[15]

多くのCCTV / セキュリティ カメラ ( IP カメラとも呼ばれる) は、特にONVIFプロファイル G、S、T を備えたカメラで RTSP ストリーミングもサポートしています。

• アストラ
• cURL（バージョン7.20.0以降—2010年2月9日^[16]）
• FFmpeg ^[17]
• Gストリーマー
• ジェットオーディオ
• LIVE555 liveMedia / openRTSP : VLCやmplayerなどの有名なクライアントで使用されるオープンソースのC++サーバーおよびクライアント ライブラリ。
• メディアプレーヤークラシック
• MPlayer
• MythTV（Freebox経由）
• クイックタイム
• リアルプレイヤー
• スカイプ
• スポティファイ
• VLCメディアプレーヤー
• ウィナンプ
• ウィンドウズメディアプレーヤー
• キシン
• ゾーンマインダー
• モーション（監視ソフトウェア）

• 「リアルタイム ストリーミング プロトコルの情報と更新」。2007 年 3 月 6 日にオリジナルからアーカイブされました。RTSP に関する中央情報リポジトリ。
• 「HTTP を介した RTSP および RTP のトンネリング」。2013 年 5 月 1 日にオリジナルからアーカイブされました。RTSP がファイアウォールや Web プロキシを介して機能するのを支援する標準ソリューション
• 「Rtsp と Rtp を使用した管理されたメディア集約」では、標準に準拠した RtspClient と RtspServer の実装を開発者に説明します。