Baud
ENJA
All protocols

RTSP

The remote control for streams: describe, set up, play, stop, in HTTP-style text.

DESCRIBE

The first question a player asks. It looks like HTTP, and that is by design.

RTSP request · DESCRIBE0163248648044D45E53S43C52R49I42B45E20 72r74t73s70p3A:2F/2F/63c61a6Dm2E.65e78x61a6Dm70p6Cl65e2E.63c6Fo6Dm2F/6Cl69i76v65e20 52R54T53S50P2F/3112E.3000DCR0ALF43C53S65e71q3A:20 3220DCR0ALF41A63c63c65e70p74t3A:20 61a70p70p6Cl69i63c61a74t69i6Fo6En2F/73s64d70p0DCR0ALF0DCR0ALFMethodSpaceURLSpaceVersionCRLFCSeq he…Accept headerBlank lineClick a field to inspect it

Whole frame

Text, line by line, just like HTTP. RTSP only controls the stream (describe, set up, play, stop); the video itself travels separately in RTP.

FieldOffsetExample valueMeaning
MethodByte 0–7DESCRIBEWhat the client asks for. DESCRIBE = 'tell me what this stream consists of'. The others: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN.
SpaceByte 80x20Separator.
URLByte 9–35rtsp://cam.example.com/liveThe stream to talk about. Note the scheme: rtsp:// (default port 554). RTSP is deliberately a lot like HTTP, but it is stateful: the server remembers a session between requests.
SpaceByte 360x20Separator.
VersionByte 37–44RTSP/1.0The protocol version.
CRLFByte 45–460D 0AEnd of the request line.
CSeq headerByte 47–55CSeq: 2A sequence number for requests. The server copies it into its reply so the client can match answers to questions, since several requests may be in flight.
Accept headerByte 56–80Accept: application/sdpThe format the client wants the description in: SDP (Session Description Protocol), a plain-text list of streams, codecs and ports.
Blank lineByte 81–820D 0AEnd of the headers. A DESCRIBE has no body.

Overview

RTSP (Real Time Streaming Protocol) is how a player talks to an IP camera or media server. Its messages look like HTTP (a request line, headers, a blank line) but it controls a session: DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN. The server remembers state between requests.

It does not carry the video. After PLAY, the camera sends RTP packets to the ports agreed in SETUP.

Key facts

Transport
TCP 554 (control)
Media
RTP/RTCP over UDP, or interleaved in TCP
Encoding
ASCII text, CRLF lines
Methods
OPTIONS DESCRIBE SETUP PLAY PAUSE TEARDOWN
Describes with
SDP
Standard
RFC 2326 / RFC 7826 (2.0)

SETUP

Negotiating where the media will be sent.

RTSP request · SETUP016324864809611253S45E54T55U50P20 72r74t73s70p3A:2F/2F/63c61a6Dm2E.65e78x61a6Dm70p6Cl65e2E.63c6Fo6Dm2F/6Cl69i76v65e2F/74t72r61a63c6Bk49I44D3D=31120 52R54T53S50P2F/3112E.3000DCR0ALF43C53S65e71q3A:20 3330DCR0ALF54T72r61a6En73s70p6Fo72r74t3A:20 52R54T50P2F/41A56V50P3B;75u6En69i63c61a73s74t3B;63c6Cl69i65e6En74t5F_70p6Fo72r74t3D=3553003003002D-3553003003110DCR0ALF0DCR0ALFMethodSpaceTrack URLVersion and CRLFCSeq headerTranspo…Blank lineClick a field to inspect it

Whole frame

The client picks its UDP ports and the server will aim RTP at them. Alternatively the media can be interleaved inside this same TCP connection, which helps through firewalls.

FieldOffsetExample valueMeaning
MethodByte 0–4SETUPSETUP = 'prepare to receive this track'. It negotiates the transport: which ports the media will use.
SpaceByte 50x20Separator.
Track URLByte 6–42rtsp://cam.example.com/live/trackID=1The control URL of one track (taken from the SDP). Video and audio are set up separately.
Version and CRLFByte 43–53RTSP/1.0Version, then end of line.
CSeq headerByte 54–62CSeq: 3Next request number.
Transport headerByte 63–112Transport: RTP/AVP;unicast;client_port=5000-5001The heart of SETUP: send RTP (profile AVP) as unicast UDP to my ports 5000 (RTP, even) and 5001 (RTCP, odd). The server answers with its own ports and a Session ID.
Blank lineByte 113–1140D 0AEnd of the headers.

A whole session

From first question to TEARDOWN, and where RTP joins in.

PlayerVLC / NVRIP cameracam.example.com:554DESCRIBECSeq: 2200 OK + SDPH.264 video, AAC audioSETUPclient_port=5000-5001200 OKSession: 4F2A91PLAYRange: npt=0-200 OKRTP-Info: seq=100RTPUDP -> :5000TEARDOWNSession: 4F2A91INITINITREADYREADYPLAYINGPLAYINGINITINIT

Whole exchange

RTSP is the remote control; RTP is the picture. Control over TCP on port 554, media over UDP on ports picked during SETUP.

  1. 1What is this stream?

    Over a TCP connection to port 554, the player asks for a description.

  2. 2Camera describes itself

    The reply carries an SDP body: two tracks (video H.264, audio AAC), their payload types and control URLs.

  3. 3Prepare the video track

    The player proposes UDP ports for RTP and RTCP.

  4. 4Session created

    The camera confirms and returns its own ports and a Session ID that every following request must carry.

  5. 5Start sending

    npt=0- means 'from the beginning (or, for live, from now) onwards'.

  6. 6Acknowledged

    The reply says the first RTP packet's sequence number and timestamp, so the player can sync.

  7. 7The video flows

    From here the control channel is quiet. Media travels as RTP over UDP to the negotiated port, with RTCP reports on the next port.

  8. 8Stop and clean up

    TEARDOWN ends the session; the camera stops sending and frees resources.

Where you meet it

  • IP cameras, CCTV, NVRs (the usual rtsp://camera/stream URL)
  • Media servers and video test streams
  • ffmpeg, VLC and GStreamer all speak it: `ffplay rtsp://...`

Watch out for

  • A stream that works in VLC but not through a firewall is usually the UDP ports in SETUP: switch the player to RTSP over TCP (interleaved).
  • Cameras often limit concurrent sessions. A stuck session with no TEARDOWN blocks a new viewer until it times out.
  • Web browsers cannot play RTSP directly: gateways convert it to HLS or WebRTC.

Standards

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

Related protocols

RTPHTTP/1.1HLS