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

リアルタイムストリーミングプロトコル
通信プロトコル
略語RTSP
目的インターネットストリーミング
開発者RealNetworksNetscapeコロンビア大学
導入1998年4月; 26年前 ( 1998-04 )
OSI層アプリケーション層(7)
ポート
  • 554/TCP
  • 554/UDP
RFC(複数)RFC  2326、7826

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

歴史

RTSPは、 RealNetworksNetscape [1]コロンビア大学によって開発されました[2]最初のドラフトは、1996年10月にNetscapeProgressive 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]

RTTP とは

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

プロトコル指令

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

ここでは基本的なRTSP要求を紹介する。OPTIONS要求のようないくつかの典型的なHTTP要求も利用可能である。デフォルトのトランスポート層ポート番号はTCPUDPの両方で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;ユニキャスト;client_port=8002-8003;server_port=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 ...
      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

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 パケット}

HTTP 経由の RTSP

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

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

RTSP 暗号化と RTSPS

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] FFmpegGStreamer、MediaMTX [12]、SharpRTSPによって実装されています。[13]

レート適応

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

実装

サーバ

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

クライアント

参考文献

  1. ^ InfoWorld Media Group, Inc. (1998年3月2日). InfoWorld. InfoWorld Media Group, Inc. p. 18. ISSN  0199-6649.
  2. ^ ラファエル・オッソ (1999)。新興通信技術ハンドブック: 次の10年。CRC Press。p. 42。ISBN 978-1-4200-4962-6
  3. ^ Rao, Anup; Lanphier, Rob. 「Real Time Streaming Protocol (RTSP)」。Ietf Datatracker 2021年2月23日閲覧。
  4. ^ 「RTSP プライム」ヘニング・シュルツリンネコロンビア大学(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) 1996 年 12 月
  5. ^ Schulzrinne, Henning ; Rao, Anup; Lanphier, Rob (1997-02-24). 「Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)」. Ietf Datatracker . 2021-02-23閲覧
  6. ^ Schulzrinne, Henning ; Rao, Anup; Lanphier, Rob (1998-01-15). 「Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)」. Ietf Datatracker . 2021-02-23閲覧
  7. ^ ab RFC 2326、リアルタイムストリーミングプロトコル (RTSP)、IETF、1998
  8. ^ シュルツリンネ、ヘニング;ラオ、アヌプ。ランフィエ、ロブ。ウェスターランド、マグナス。マーティン・シュティーマーリング(2016年12月)。スティマーリング、M (編)。 「リアルタイム ストリーミング プロトコル バージョン 2.0」。tools.ietf.org土井: 10.17487/RFC7826 2021年2月23日閲覧
  9. ^ 「開発者 - QuickTime - 氷床からの手紙」 2013-05-01。2013-05-01時点のオリジナルよりアーカイブ。2024-09-22閲覧
  10. ^ 「サービス名とトランスポート プロトコル ポート番号レジストリ」。
  11. ^ 「セキュア RTSP ストリーミング - SRTP/RTSPS」。
  12. ^ メディアMTX
  13. ^ 「Ngraziano/SharpRTSP」。GitHub
  14. ^ サントス、ヒューゴ;クルーズ、ルイ・サントス。 Nunes、Mário Serafim (2010)、「Rate Adaptation Technique for WebTV」、User Centric Media、Recture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering、vol. 40、161–168、土井:10.1007/978-3-642-12630-7_19、ISBN 978-3-642-12629-1
  15. ^ 「YouTube Mobile A Bust! (Getting 3GP/RTSP to work on WM5)」. Chris Duke . 2007-06-23 . 2021年5月29日閲覧
  16. ^ cURL — 変更点
  17. ^ 「FFmpeg ドキュメント」。FFmpeg プロジェクト。2012 年 9 月 11 日。セクション 20.19。2012年 9 月 11 日に取得
  • 「リアルタイム ストリーミング プロトコルの情報と更新」。2007 年 3 月 6 日にオリジナルからアーカイブされました。RTSP に関する中央情報リポジトリ。
  • 「HTTP を介した RTSP および RTP のトンネリング」。2013 年 5 月 1 日にオリジナルからアーカイブされました。RTSP がファイアウォールや Web プロキシを介して機能するのを支援する標準ソリューション
  • 「Rtsp と Rtp を使用した管理されたメディア集約」では、標準に準拠した RtspClient と RtspServer の実装を開発者に説明します。
Retrieved from "https://en.wikipedia.org/w/index.php?title=Real-Time_Streaming_Protocol&oldid=1247291684"