Real-Time Streaming Protocol


The Real-Time Streaming Protocol is an application-level network protocol designed for multiplexing and packetizing multimedia transport streams over a suitable transport protocol.
RTSP is used in entertainment and communications systems to control streaming media servers.
The protocol is used for establishing and controlling media sessions between endpoints.
Clients of media servers issue commands such as play, record and pause to facilitate real-time control of the media streaming from the server to a client or from a client to the server.

History

RTSP was developed by RealNetworks, Netscape and Columbia University.
The first draft was submitted to IETF in October 1996 by Netscape and Progressive Networks, after which Henning Schulzrinne from Columbia University submitted "RTSP՚" in December 1996.
The two drafts were merged for standardization by the Multiparty Multimedia Session Control Working Group of the Internet Engineering Task Force and further drafts were published by the working group.
The Proposed Standard for RTSP was published as RFC 2326 in 1998.
RTSP 2.0 was published as RFC 7826 in 2016 as a replacement of RTSP 1.0.
Version 2.0 is based on version 1.0 but is not backwards compatible other than in the basic version negotiation mechanism, and remains a Proposed Standard.

RTP

The transmission of streaming data itself is not a task of RTSP. Most RTSP servers use the Real-time Transport Protocol in conjunction with Real-time Control Protocol 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.

Protocol directives

While similar in some ways to HTTP, RTSP defines control sequences useful in controlling multimedia playback. While HTTP is stateless, RTSP has a state; an identifier is used when needed to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection and, while most RTSP control messages are sent by the client to the server, some commands travel in the other direction.
Presented here 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, the latter being rarely used for the control requests.

OPTIONS


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


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


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


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


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


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:

TEARDOWN


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


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


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


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


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
S->C: $\000
S->C: $\001

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, and then sends the RTSP Command Connection via a pair of HTTP connections. One 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 the RTP Video and Audio data.
RTSP 2.0 defines several methods for encryption and introduces a new rtsps:// URL and many of these have been incorporated into RFC2326 RTSP 1.0 Clients and Servers.RTSPS URL - This method uses a TLS Socket 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 connectionRTSP over HTTPS - this method interleaves the RTP Video and Audio data into the RTSP Command Connection 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 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

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

Client