Baud
ENJA
プロトコル一覧

RTSP

ストリームのリモコン。記述・準備・再生・停止を、HTTP 風のテキストで。

DESCRIBE

プレイヤーが最初にする質問です。HTTP に似ているのは意図的な設計です。

RTSP リクエスト・DESCRIBE0163248648044D45E53S43C52R49I42B45E20 72r74t73s70p3A:2F/2F/63c61a6Dm2E.65e78x61a6Dm70p6Cl65e2E.63c6Fo6Dm2F/6Cl69i76v65e20 52R54T53S50P2F/3112E.3000DCR0ALF43C53S65e71q3A:20 3220DCR0ALF41A63c63c65e70p74t3A:20 61a70p70p6Cl69i63c61a74t69i6Fo6En2F/73s64d70p0DCR0ALF0DCR0ALFメソッドスペースURLスペースバージョン改行CSeq ヘ…Accept ヘッダ空行フィールドをクリックして中身を見る

フレーム全体

HTTP と同じく、行ごとのテキストです。RTSP は再生の制御（記述・準備・再生・停止）だけを担い、映像そのものは別に RTP で流れます。

フィールド位置例の値意味
メソッド0–7 バイト目DESCRIBEクライアントの依頼内容。DESCRIBE =「このストリームの構成を教えて」。ほかに OPTIONS、SETUP、PLAY、PAUSE、TEARDOWN があります。
スペース8 バイト目0x20区切り。
URL9–35 バイト目rtsp://cam.example.com/live対象のストリーム。スキームは rtsp://（既定ポート 554）。RTSP は HTTP によく似せてありますが、リクエストをまたいでサーバがセッションを覚える、状態を持つ方式です。
スペース36 バイト目0x20区切り。
バージョン37–44 バイト目RTSP/1.0プロトコルのバージョン。
改行45–46 バイト目0D 0Aリクエスト行の終わり。
CSeq ヘッダ47–55 バイト目CSeq: 2リクエストの通し番号です。サーバが応答にそのまま写すので、クライアントは複数の要求が飛んでいても、答えと質問を対応づけられます。
Accept ヘッダ56–80 バイト目Accept: application/sdpクライアントが記述を受け取りたい形式。SDP（Session Description Protocol）は、ストリーム・コーデック・ポートを並べたテキストです。
空行81–82 バイト目0D 0Aヘッダの終わり。DESCRIBE にボディはありません。

概要

RTSP（Real Time Streaming Protocol）は、プレイヤーが IP カメラやメディアサーバと話すための仕組みです。メッセージは HTTP に似ていますが（リクエスト行・ヘッダ・空行）、セッションを制御します。DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN。サーバはリクエストの間、状態を覚えています。

映像そのものは運びません。PLAY のあと、カメラは SETUP で合意したポートへ RTP パケットを送ります。

基本情報

トランスポート
TCP 554 (control)
メディア
UDP 上の RTP/RTCP、または TCP に混ぜて
符号化
ASCII テキスト、CRLF 区切り
メソッド
OPTIONS DESCRIBE SETUP PLAY PAUSE TEARDOWN
記述形式
SDP
規格
RFC 2326 / RFC 7826 (2.0)

SETUP

メディアの送り先を取り決めます。

RTSP リクエスト・SETUP016324864809611253S45E54T55U50P20 72r74t73s70p3A:2F/2F/63c61a6Dm2E.65e78x61a6Dm70p6Cl65e2E.63c6Fo6Dm2F/6Cl69i76v65e2F/74t72r61a63c6Bk49I44D3D=31120 52R54T53S50P2F/3112E.3000DCR0ALF43C53S65e71q3A:20 3330DCR0ALF54T72r61a6En73s70p6Fo72r74t3A:20 52R54T50P2F/41A56V50P3B;75u6En69i63c61a73s74t3B;63c6Cl69i65e6En74t5F_70p6Fo72r74t3D=3553003003002D-3553003003110DCR0ALF0DCR0ALFメソッドスペーストラック URLバージョンと改行CSeq ヘッダTranspo…空行フィールドをクリックして中身を見る

フレーム全体

クライアントが UDP ポートを決め、サーバはそこへ RTP を送ります。別の方法として、この同じ TCP 接続の中にメディアを交互に混ぜて流すこともでき、ファイアウォール越えに役立ちます。

フィールド位置例の値意味
メソッド0–4 バイト目SETUPSETUP =「このトラックを受け取る準備をする」。メディアが使うポートなど、トランスポートを取り決めます。
スペース5 バイト目0x20区切り。
トラック URL6–42 バイト目rtsp://cam.example.com/live/trackID=11 つのトラックの制御 URL（SDP から取得）。映像と音声は別々に準備します。
バージョンと改行43–53 バイト目RTSP/1.0バージョンと、行の終わり。
CSeq ヘッダ54–62 バイト目CSeq: 3次のリクエスト番号。
Transport ヘッダ63–112 バイト目Transport: RTP/AVP;unicast;client_port=5000-5001SETUP の核心。「RTP（AVP プロファイル）をユニキャスト UDP で、私のポート 5000（RTP、偶数）と 5001（RTCP、奇数）へ送って」。サーバは自分のポートと Session ID で答えます。
空行113–114 バイト目0D 0Aヘッダの終わり。

セッション全体

最初の質問から TEARDOWN まで、そして RTP が加わる場所。

プレイヤーVLC / NVRIP カメラcam.example.com:554DESCRIBECSeq: 2200 OK + SDPH.264 video, AAC audioSETUPclient_port=5000-5001200 OKSession: 4F2A91PLAYRange: npt=0-200 OKRTP-Info: seq=100RTPUDP -> :5000TEARDOWNSession: 4F2A91INITINITREADYREADYPLAYINGPLAYINGINITINIT

やり取りの全体

RTSP はリモコン、RTP は映像そのものです。制御はポート 554 の TCP、メディアは SETUP で決めたポートの UDP を使います。

  1. 1このストリームは何？

    ポート 554 への TCP 接続の上で、プレイヤーが記述を求めます。

  2. 2カメラが自分を説明する

    応答のボディに SDP が入っています。2 つのトラック（映像 H.264、音声 AAC）と、その種別・制御 URL。

  3. 3映像トラックを準備する

    プレイヤーが、RTP と RTCP 用の UDP ポートを提案します。

  4. 4セッションが作られる

    カメラが確認し、自分のポートと、以後のすべてのリクエストが付ける Session ID を返します。

  5. 5送信を始めて

    npt=0- は「最初から（ライブなら今から）ずっと」の意味です。

  6. 6了解

    応答が最初の RTP パケットのシーケンス番号とタイムスタンプを伝え、プレイヤーが同期できます。

  7. 7映像が流れる

    ここから制御チャネルは静かになります。メディアは取り決めたポートへ、UDP 上の RTP として流れ、隣のポートで RTCP レポートが交わされます。

  8. 8停止して後片付け

    TEARDOWN でセッションを終えます。カメラは送信を止め、リソースを解放します。

使われる場面

  • IP カメラ、防犯カメラ、NVR（おなじみの rtsp://camera/stream の URL）
  • メディアサーバ、映像のテスト配信
  • ffmpeg・VLC・GStreamer がすべて対応: `ffplay rtsp://...`

つまずきやすい点

  • VLC では見えるのにファイアウォール越しで見えないときは、たいてい SETUP の UDP ポートが原因です。プレイヤーを TCP（インターリーブ）に切り替えます。
  • カメラは同時セッション数に制限があります。TEARDOWN されずに残ったセッションは、タイムアウトまで新しい視聴者を締め出します。
  • ブラウザは RTSP を直接再生できません。ゲートウェイで HLS や WebRTC に変換します。

出典・規格

  • RFC 2326: RTSP 1.0
  • RFC 7826: RTSP 2.0
  • RFC 8866: SDP

関連するプロトコル

RTPHTTP/1.1HLS