Real-Time Streaming Protocol Version 2.0
obsoletes
- rfc-2326 — Real Time Streaming Protocol (RTSP)
Extracted elements (31)
Absolute time in RTSP uses a restricted ISO 8601 format (YYYYMMDDThhmmssZ) rather than RFC 3339. This choice is historic — RTSP 2.0 retains the format from RTSP 1.0 to preserve continuity even though RFC 3339's motivations for choosing a subset of ISO 8601 also apply.
The Speed header uses a range (lower bound to upper bound) rather than a single value to resolve the conflict between buffer-filling (where quality reduction is unacceptable) and local-playout scaling (where exact speed is required). The server operates at the highest speed within the range that the network path supports, degrading quality only if it cannot sustain even the minimum speed.
RTSP 2.0 is not backwards compatible with RTSP 1.0 except in the basic version negotiation mechanism. Key incompatibilities include changed PLAY-in-Play-state behavior, a revised extensibility model, and syntax changes to several headers.
Absolute time expressed in RTSP MUST use UTC (GMT); no time zone offsets are allowed. The format is YYYYMMDDThhmmss.ssZ based on ISO 8601.
An RTSP server MUST respond with error code 501 (Not Implemented) to any request carrying the 'rtspu' URI scheme, as unreliable transport is unspecified in RTSP 2.0.
For backward compatibility, all RTSP 2.0 implementations are REQUIRED to support receiving NPT values in npt-hhmmss notation without leading zeros (as allowed by RTSP 1.0).
For the 'rtsp' URI scheme, if no port is provided, port 554 MUST be used. For 'rtsps', if no port is provided, TCP port 322 MUST be used.
If the recipient of a new RTSP method does not understand the request, it MUST respond with error code 501 (Not Implemented). A server MUST list the methods it supports using the Public response-header.
RTSP 2.0 requires clients and servers to implement TCP and TLS over TCP as mandatory transports for RTSP messages. The 'rtsp' URI scheme requires a reliable protocol (TCP), while 'rtsps' identifies a reliable transport using TLS.
Session identifiers MUST be generated using cryptographically random methods (see RFC 4086). It is RECOMMENDED that a session identifier contain 128 bits of entropy (approximately 22 characters from a high-quality generator). Session identifiers are strings of length between 8 and 128 characters.
The NPT special constant 'now' MAY only be used for live events and MUST NOT be used for on-demand (non-live) content.
The RTSP IRI format MUST use the rules and transformation for IRIs to URIs as defined in RFC 3987. An absolute RTSP URI requires the authority part; a host identity MUST be provided.
The RTSP major and minor version numbers MUST be treated as separate integers and each MAY be incremented higher than a single digit. Leading zeros SHALL NOT be sent and MUST be ignored by recipients.
An RTSP session is a stateful entity established by a successful SETUP request (200 OK response). It persists until timed out by the server or explicitly removed by TEARDOWN. A session can aggregate one or more media streams under common control.
Feature tags (Section 4.5) are unique identifiers designating optional RTSP capabilities. They appear in Require, Proxy-Require, Proxy-Supported, Supported, and Unsupported headers to negotiate feature availability. The mandatory baseline feature tag is 'play.basic'.
PLAY_NOTIFY is a server-to-client request used to signal end-of-stream, media-properties updates, or scale changes during an ongoing session. It carries a Notify-Reason header indicating the notification type.
Scale and Speed headers provide independent media delivery manipulations. Scale (Section 18.46) adjusts the ratio of content time to playback time (fast-forward, slow-motion, reverse). Speed (Section 18.50) adjusts the ratio of playback time delivered per wallclock time, expressed as a range to allow bandwidth-adaptive delivery.
The CSeq header (Section 18.20) contains a sequence number for every RTSP request and corresponding response. It is used to correlate requests with responses, especially during pipelining.
The Pipelined-Requests header (Section 18.33) allows a client to bind multiple requests together with a client-selected identifier, enabling the server to treat them as if they included the session identifier; this avoids extra round trips during aggregated session establishment.
The PLAY method initiates media delivery; the Range header specifies where delivery starts and optionally ends. The PLAY response contains RTP-Info synchronization data. A PLAY request received while already in Play state updates the current delivery parameters.
The SETUP method creates the RTSP session context. The Transport header in the SETUP request carries transport parameters and may contain a prioritized list of alternatives. The server selects one and includes it in the SETUP response along with the Session header carrying the new session identifier.
The Transport header (Section 18.54) is used in SETUP to negotiate media delivery parameters including transport protocol, delivery mode (unicast/multicast), client/server ports, SSRC, and interleaving channel IDs for embedded binary data.
IANA registries created or updated by RFC 7826 include: RTSP Feature Tags, RTSP Methods, RTSP Status Codes, RTSP Headers, Accept-Credentials Policies and Hash Algorithms, Cache-Control Cache Directive Extensions, Media Properties, Notify-Reason Values, Range Header Formats, Terminate-Reason Header parameters, RTP-Info Header Parameters, Seek-Style Policies, Transport Protocol Identifiers/Modes/Parameters, URI schemes (rtsp, rtsps, rtspu), SDP attributes, and the text/parameters media type.
The RTSP Methods registry (Section 22.2) records the defined RTSP methods: OPTIONS, DESCRIBE, SETUP, PLAY, PLAY_NOTIFY, PAUSE, TEARDOWN, GET_PARAMETER, SET_PARAMETER, and REDIRECT. New methods require IETF Review.
A remote DoS attack (Section 21.2.1) can be launched by directing a media server to send high-bandwidth streams to a victim address by manipulating the Transport header destination. Servers MUST take precautions to verify delivery destinations, such as requiring unicast delivery only to the client's source address or implementing a reachability check.
RTSP signaling threats include eavesdropping, message replay, and man-in-the-middle attacks; TLS over the 'rtsps' scheme is the primary mitigation. For proxy chains, the Accept-Credentials mechanism and user-approved TLS procedure (Section 19.3) allow clients to authorize specific proxy credentials.
Session identifiers do not provide security against session hijacking unless kept confidential by client, server, and trusted proxies. A 128-bit cryptographically random session ID is recommended, but confidentiality of the identifier is the primary defense.
The RTSP session state machine (Appendix B) defines three states: Init (no session or just created), Ready (session established but not delivering media), and Play (media being delivered). Transitions are triggered by SETUP (Init→Ready), PLAY (Ready→Play), PAUSE (Play→Ready), and TEARDOWN (any→Init/terminated).
Embedded (interleaved) binary data (Section 14) multiplexes RTP/RTCP packets over the RTSP TCP connection. Each binary frame is prefixed with a '$' character, a 1-byte channel identifier, and a 2-byte big-endian data length, followed by the payload.
RTSP messages are text-based. A request starts with a method line (method, URI, RTSP-version), followed by header lines, ended by two CRLF pairs. An optional binary message body follows, with length given by Content-Length. Responses begin with a status line (RTSP-version, status code, reason phrase).
Session identifiers are ASCII strings of 8–128 characters. The NPT time format uses either npt-hhmmss (hh:mm:ss[.fraction]) or npt-sec (seconds[.fraction], 1–19 digits). SMPTE timestamps use hours:minutes:seconds:frames.subframes format anchored at the start of the media clip.