Real-Time Streaming Protocol

RTP

The transmission of streaming data itself is not a task of RTSP. Most RTSP servers use the Real-time Transport Protocol (RTP) in conjunction with Real-time Control Protocol (RTCP) for media stream delivery. However, some vendors implement proprietary transport protocols. The RTSP server software from RealNetworks, for example, also used RealNetworks' proprietary Real Data Transport (RDT).

Protocol directives

While similar in some ways to HTTP, RTSP defines control sequences that are useful in controlling multimedia playback. While HTTP is stateless, RTSP has a state; an identifier is used to track concurrent sessions when needed. Like HTTP, RTSP uses TCP to maintain an end-to-end connection. While most RTSP control messages are sent by the client to the server, some commands travel in the other direction (i.e., from server to client).

Presented below are the basic RTSP requests. Some typical HTTP requests, like the OPTIONS request, are also available. The default transport layer port number is 554 for both TCP and UDP, but the latter is rarely used for control requests.

OPTIONS

An OPTIONS request returns the request types the server will accept.

C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

DESCRIBE

A DESCRIBE request includes an RTSP rtsp:// URL, and the type of reply data that can be handled. This reply includes the presentation description, typically in Session Description Protocol (SDP) format. Among other things, the presentation description lists the media streams controlled with the aggregate URL. In a typical case, there is one media stream each for audio and video streams. The media stream URLs are either obtained directly from the SDP control fields or by appending the SDP control field to the aggregate URL.

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 2 S->C: RTSP/1.0 200 OK CSeq: 2 Content-Base: rtsp://example.com/media.mp4 Content-Type: application/sdp Content-Length: 460 m=video 0 RTP/AVP 96 a=control:streamid=0 a=range:npt=0-7.741000 a=length:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"video/MP4V-ES" a=AvgBitRate:integer;304018 a=StreamName:string;"hinted video track" m=audio 0 RTP/AVP 97 a=control:streamid=1 a=range:npt=0-7.712000 a=length:npt=7.712000 a=rtpmap:97 mpeg4-generic/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=AvgBitRate:integer;65790 a=StreamName:string;"hinted audio track"

SETUP

A SETUP request specifies how a single media stream will be transported. This must be done before a PLAY request is sent. The request contains the media stream URL and a transport specifier. This specifier typically includes a local port for receiving RTP data (audio or video), and another for RTCP data (meta information). The server reply usually confirms the chosen parameters and fills in the missing parts, such as the server's chosen ports. Each media stream must be configured using SETUP before an aggregate play request may be sent.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8000-8001 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD Session: 12345678 C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD Session: 12345678

PLAY

A PLAY request will cause one or all media streams to be played. Play requests can be stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all media streams), or a single media stream URL (to play only that stream). A range can be specified. If no range is specified, the stream is played from the beginning and plays to the end, or if the stream is paused, it is resumed at the point it was paused.

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Range: npt=5-20 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSE

A PAUSE request temporarily halts one or all media streams, to be resumed later via a PLAY request. The request contains an aggregate or media stream URL. A range parameter on a PAUSE request specifies when to pause. When the range parameter is omitted, the pause occurs immediately and indefinitely.

C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 5 Session: 12345678

RECORD

This method initiates recording a range of media data according to the presentation description. The timestamp reflects the start and end time (in UTC). If no time range is given, use the start or end time provided in the presentation description. If the session has already started, recording commences immediately. The server decides whether to store the recorded data under the request URI or another URI. If the server does not use the request URI, the response should be 201 and contain an entity that describes the states of the request and refers to the new resource, as well as containing a Location header.

C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Session: 12345678

ANNOUNCE

The ANNOUNCE method serves two purposes:

When sent from client to server, ANNOUNCE posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, ANNOUNCE updates the session description in real time. If a new media stream is added to a presentation (e.g., during a live presentation), the whole presentation description must be sent again, rather than just the additional components, so that components can be deleted.

<span class="plainlinks" id="mwhA"> C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 7 Date: 23 Jan 1997 15:35:06 GMT Session: 12345678 Content-Type: application/sdp Content-Length: 332 v=0 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=<a rel="mw:ExtLink nofollow" href="http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps" class="external free" id="mwhQ">http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps</a> [email protected] (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSeq: 7 </span>

TEARDOWN

A TEARDOWN request is used to terminate the session. It stops all media streams and frees all session-related data on the server.

C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 8

GET_PARAMETER

The GET_PARAMETER request retrieves the value of a parameter of a presentation or stream specified in the URI. The content of the reply and response is left to the implementation. GET_PARAMETER with no entity body may be used to test client or server liveness ("ping").

S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 Content-Type: text/parameters Session: 12345678 Content-Length: 15 packets_received jitter C->S: RTSP/1.0 200 OK CSeq: 9 Content-Length: 46 Content-Type: text/parameters packets_received: 10 jitter: 0.3838

SET_PARAMETER

This method requests to set the value of a parameter for a presentation or stream specified by the URI.

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 Content-length: 20 Content-type: text/parameters barparam: barstuff S->C: RTSP/1.0 451 Invalid Parameter CSeq: 10 Content-length: 10 Content-type: text/parameters barparam

REDIRECT

A REDIRECT request informs the client that it must connect to another server location. It contains the mandatory header Location, which indicates that the client should issue requests for that URL. It may contain the parameter Range, which indicates when the redirection takes effect. If the client wants to continue to send or receive media for this URI, the client MUST issue a TEARDOWN request for the current session and a SETUP for the new session at the designated host.

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 11 Location: rtsp://bigserver.com:8001 Range: clock=19960213T143205Z-

Embedded (Interleaved) Binary Data

Certain firewall designs or other circumstances may force a server to interleave RTSP methods and stream data. This interleaving should generally be avoided unless necessary, since it complicates client and server operation and imposes additional overhead. Interleaved binary data should only be used if RTSP is carried over TCP.

Stream data, such as RTP packets, is encapsulated by an ASCII dollar sign (24 hexadecimal), followed by a one-byte channel identifier, followed by the length of the encapsulated binary data as a binary, two-byte integer in network byte order. The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers. Each $ block contains exactly one upper-layer protocol data unit, e.g., one RTP packet.

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;interleaved=0-1 S->C: RTSP/1.0 200 OK CSeq: 3 Date: 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;interleaved=0-1 Session: 12345678 C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 Date: 05 Jun 1997 18:59:15 GMT RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\001{2 byte length}{"length" bytes RTCP packet}

RTSP over HTTP

RTSP over HTTP was defined by Apple in 1999. It interleaves the RTP Video and Audio data into the RTSP Command Connection (as defined in RFC2326), and then sends the RTSP Command Connection via a pair of HTTP connections. One of these is a long-running GET connection, and the other is a long-running POST connection.

This method is also used in the ONVIF IP Camera standard, and can be combined with HTTPS for secure and encrypted video and audio.

RTSP Encryption and RTSPS

There are several different methods for encrypting RTSP command messages and RTP Video and Audio data.

RTSP 2.0 (RFC7826) defines several methods for encryption and introduces a new rtsps:// URL. Many of these have been incorporated into RFC2326 RTSP 1.0 Clients and Servers.

• RTSPS URL (using the rtsps:// URL) - This method uses a TLS Socket (default of Port 322) to establish an encrypted connection between the RTSP client and the RTSP Server.
  Video and Audio can then sent in one of two ways:
  • TCP Video/Audio - The RTP Video and Audio is sent interleaved with the RTSP Commands over the already encrypted TLS connection.
  • UDP and Multicast-UDP Video/Audio - the RTP Video and Audio is encrypted using the Secure RTP (SRTP) protocol and sent in parallel to the RTSPS TLS connection.
• RTSP over HTTPS - this method interleaves the RTP Video and Audio data into the RTSP Command Connection (as defined in RFC2326) and then sends the RTSP Command Connection via a pair of encrypted HTTPS connections. It uses Port 443 by default.

IANA have reserved the rtsps:// URL prefix and Port 322 for RTSPS. As of September 2024, RTSP over HTTPS has been implemented in several ONVIF IP Cameras and RTSPS (using the rtsps:// URL) has been implemented by Axis and Bosch CCTV Cameras, FFmpeg, GStreamer, MediaMTX, Ant Media Server and SharpRTSP.

Rate adaptation

RTSP using RTP and RTCP allows for the implementation of rate adaptation.

Implementations

Server

• Ant Media Server: The Community version supports pulling from RTSP/S sources and can livestream using HLS or record in MP4. The Enterprise version can convert RTSP to WebRTC with approximately 200-500ms end-to-end latency.
• Darwin Streaming Server is an open source version of QuickTime Streaming Server maintained by Apple.
• GStreamer based RTSP Server and client.
• Helix DNA Server is RealNetworks' streaming server, which comes in both open-source and proprietary versions.
• Helix Universal Server is RealNetworks' commercial streaming server for RTSP, RTMP, iOS, Silverlight and HTTP streaming media clients.
• LIVE555 liveMedia / openRTSP are open source C++ server and client libraries used in well-known clients like VLC and mplayer.
• Motion is a free CCTV software application for Linux.
• Nimble Streamer supports RTSP pull and announce input, with TCP interleaved playback output.
• OvenMediaEngine is an open source low-latency streaming server that supports RTSP push input.
• pvServer: Formerly called PacketVideo Streaming Server, this is Alcatel-Lucent's streaming server product.
• QuickTime Streaming Server is Apple's closed-source streaming server that ships with Mac OS X Server.
• VideoLAN is an open source media player and streaming server.
• Windows Media Services is a Microsoft streaming server previously included with Windows Server that uses RTSP modified with Windows Media extensions.
• Wowza Streaming Engine is a multi-format streaming server for RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, Smooth Streaming, MPEG-DASH), and WebRTC.
• YouTube implemented a mobile web front end in June 2007, which serves video through this protocol.

Many CCTV / Security cameras, often called IP cameras, support RTSP streaming too, especially those with ONVIF profiles G, S, T.

Client

• Astra
• cURL (beginning with version 7.20.0—9 February 2010)
• FFmpeg
• GStreamer
• JetAudio
• LIVE555 liveMedia / openRTSP: Open source C++ server and client libraries used in well-known clients like VLC and mplayer.
• Media Player Classic
• MPlayer
• MythTV via Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• VLC media player
• Winamp
• Windows Media Player
• xine
• ZoneMinder
• Motion (surveillance software)