Real Time Streaming Protocol (RTSP)
obsoleted by
- rfc-7826 — Real-Time Streaming Protocol Version 2.0
Extracted elements (33)
Including all transport initialization in SETUP (rather than deriving it from DESCRIBE) spares firewalls and intermediate devices the complex task of parsing DESCRIBE responses. This design makes RTSP 'firewall friendly' by concentrating transport parameters in a single method.
RTSP does not support HTTP chunked transfer encoding and requires Content-Length when a body is present. Since presentation descriptions are moderate in size and can be determined dynamically, chunked encoding is unnecessary and its absence simplifies implementation.
RTSP is text-based (UTF-8) rather than binary because text protocols are easier to extend with optional self-describing parameters, allow easy prototyping in scripting languages, and the low frequency of commands makes processing efficiency a non-issue.
RTSP requires the absolute URI (including scheme, host, and port) in every request line rather than just the absolute path as in HTTP. This simplifies virtual hosting and avoids HTTP's backward-compatibility requirement for the separate Host header, which does not apply to RTSP.
RTSP is intentionally similar in syntax to HTTP/1.1 but differs fundamentally: the server maintains state by default, both client and server can issue requests, data is carried out-of-band by a separate protocol, and RTSP uses UTF-8 (ISO 10646) rather than ISO 8859-1.
While most real-time media will use RTP as a transport protocol, RTSP operation does not depend on RTP. RTSP data MAY be interleaved with RTP and RTCP packets on the same TCP connection using the embedded binary data mechanism.
A client MUST NOT issue a PLAY request until any outstanding SETUP requests have been acknowledged as successful. The server MUST queue PLAY requests to be executed in order, delaying any PLAY request that arrives while a previous one is still active.
A conference identifier MUST be globally unique. For H.323, the conferenceID value is to be used.
A server MUST send its responses to pipelined requests in the same order that the requests were received.
A session identifier MUST be chosen randomly and MUST be at least eight octets long to make guessing it more difficult.
A SET_PARAMETER request SHOULD only contain a single parameter to allow the client to determine why a particular request failed. If the request contains several parameters, the server MUST only act if all parameters can be set successfully.
After resuming playback or recording following a PAUSE, synchronization of the tracks MUST be maintained. A PAUSE request discards all queued PLAY requests, but the pause point in the media stream MUST be maintained.
An RTSP message MUST contain a Content-Length header whenever that message contains a payload. RTSP does not support HTTP/1.1 chunked transfer coding and requires Content-Length.
If a reliable transport protocol is used to carry RTSP, requests MUST NOT be retransmitted; the RTSP application MUST instead rely on the underlying transport to provide reliability. Double retransmission at both layers would exacerbate congestion.
If a request is repeated because of lack of acknowledgement, the request MUST carry the original CSeq sequence number (i.e., the sequence number is not incremented).
If a server does not support a particular method, it MUST return '501 Not Implemented' and a client SHOULD not try that method again for this server.
If a SETUP request to a server includes a session identifier, the server MUST bundle this setup request into the existing session or return error '459 Aggregate Operation Not Allowed'.
RTSP applications MUST understand the class of any status code (indicated by the first digit) and treat any unrecognized response as equivalent to the x00 status code of that class. An unrecognized response MUST NOT be cached.
Systems implementing RTSP MUST support carrying RTSP over TCP and MAY support UDP. The default port for the RTSP server is 554 for both UDP and TCP.
The DESCRIBE response MUST contain all media initialization information for the resource(s) it describes. Servers SHOULD NOT use the DESCRIBE response as a means of media indirection.
Transport parameters for the media stream MUST only be set with the SETUP command, not SET_PARAMETER. This restriction exists for the benefit of firewalls.
RTSP defines eleven methods: DESCRIBE, ANNOUNCE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, RECORD, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. PLAY, SETUP, TEARDOWN, and OPTIONS are required; DESCRIBE and PAUSE are recommended; others are optional.
The CSeq header field carries a sequence number for each distinct RTSP request-response pair. Every request must carry a CSeq, and every response must echo the CSeq of the corresponding request.
The Range header supports three timestamp formats: NPT (Normal Play Time, relative to presentation start), SMPTE relative timestamps (hours:minutes:seconds:frames for frame-level accuracy), and absolute UTC clock time. Media servers supporting playback MUST support NPT.
The Session header identifies an RTSP session across multiple requests. The server generates session identifiers in response to SETUP requests; all state-modifying methods use this header to identify the session being manipulated.
The Transport header in SETUP specifies transport parameters for data transmission including protocol (RTP/AVP), unicast/multicast, client and server ports, and TTL. The client proposes acceptable parameters; the server response contains the selected parameters.
IANA maintains a registry of RTSP option tags used in Require and Proxy-Require headers. Registrants must provide the option name (no spaces, control characters, or periods; SHOULD be ≤20 characters), change control information, a reference to a description, and contact info for proprietary options.
For unicast delivery, the client provides the destination address, which provides a degree of access control. For multicast, the server chooses the address for live/near-on-demand use, while client-specified multicast addresses are used only when joining a pre-established conference.
Session identifiers must be chosen randomly and be at least 8 octets to prevent session hijacking by guessing. RTSP reuses HTTP authentication mechanisms (Basic and Digest) for access control, and may also employ transport or network layer security.
RTSP defines three server-side states: INIT (no session resources), READY (resources allocated via SETUP but not streaming), and PLAYING/RECORDING (active data delivery). Transitions: INIT→READY on SETUP success; READY→PLAYING on PLAY/RECORD; PLAYING→READY on PAUSE; any→INIT on TEARDOWN.
An RTSP request begins with a Request-Line of the form: Method SP Request-URI SP RTSP-Version CRLF. Unlike HTTP, the Request-URI is always the absolute URL including scheme, host, and port.
Embedded (interleaved) binary data is encapsulated in the RTSP stream with a '$' magic byte (decimal 36), followed by a 1-byte channel identifier, and a 2-byte big-endian length field, followed by the binary data (e.g., RTP or RTCP packets).
RTSP is a text-based protocol using ISO 10646 (UTF-8) encoding. Lines are terminated by CRLF, but receivers SHOULD be prepared to interpret bare CR or LF as line terminators. Messages can be carried over any 8-bit-clean transport.