The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video. RTSP does not typically deliver the continuous streams itself, although interleaving of the continuous media stream with the control stream is possible. In other words, RTSP acts as a "network remote control" for multimedia servers. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. RTSP is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms bases upon RTP.
There is no notion of an RTSP connection; instead, a server maintains a session labeled by an identifier. An RTSP session is in no way tied to a transport-level connection such as a TCP connection. During an RTSP session, an RTSP client may open and close many reliable transport connections to the server to issue RTSP requests. Alternatively, it may use a connectionless transport protocol such as UDP.
The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry continuous media. RTSP is intentionally similar in syntax and operation to HTTP/1.1 so that extension mechanisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important aspects from HTTP:
- RTSP introduces a number of new methods and has a different protocol identifier.
- An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless nature of HTTP.
- Both an RTSP server and client can issue requests.
- Data is carried out-of-band by a different protocol, in most cases.
- RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,consistent with current HTML internationalization efforts.
- The Request-URI always contains the absolute URI. Because of backward compatibility with a historical blunder, HTTP/1.1 carries only the absolute path in the request and puts the host name in a separate header field.
The protocol supports the following operations:
- Retrieval of media from media server: The client can request a presentation description via HTTP or some other method.
- Invitation of a media server to a conference: A media server can be "invited" to join an existing conference, either to play back media into the presentation or to record all or a subset of the media in a presentation.
- Addition of media to an existing presentation: Particularly for live presentations, it is useful if the server can tell the client about additional media becoming available
Protocol Structure
RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding. Lines are terminated by CRLF, but receivers should be prepared to also interpret CR and LF by themselves as line terminators. The header fields are summarized as follows:
| Header | type | support | methods |
| Accept | R | opt. | entity |
| Accept-Encoding | R | opt. | entity |
| Accept-Language | R | opt. | all |
| Allow | r | opt. | all |
| Authorization | R | opt. | all |
| Bandwidth | R | opt. | all |
| Blocksize | R | opt. | All but OPTIONS, TEARDOWN |
| Cache-Control | g | opt. | SETUP |
| Conference | R | opt. | SETUP |
| Connection | g | req. | all |
| Content-Base | e | opt. | entity |
| Content-Encoding | e | req. | SET_PARAMETER |
| Content-Encoding | e | req. | DESCRIBE, ANNOUNCE |
| Content-Language | e | req. | DESCRIBE, ANNOUNCE |
| Content-Length | e | req. | SET_PARAMETER, ANNOUNCE |
| Content-Length | e | req. | entity |
| Content-Location | e | opt. | entity |
| Content-Type | e | req. | SET_PARAMETER, ANNOUNCE |
| Content-Type | r | req. | entity |
| CSeq | g | req. | all |
| Date | g | opt. | all |
| Expires | e | opt. | DESCRIBE, ANNOUNCE |
| From | R | opt. | all |
| If-Modified-Since | R | opt. | DESCRIBE, SETUP |
| Last-Modified | e | opt. | entity |
| Proxy-Authenticate | |||
| Proxy-Require | R | req. | all |
| Public | r | opt. | all |
| Range | R | opt. | PLAY, PAUSE, RECORD |
| Range | r | opt. | PLAY, PAUSE, RECORD |
| Referer | R | opt. | all |
| Require | R | req. | all |
| Retry-After | r | opt. | all |
| RTP-Info | r | req. | PLAY |
| Scale | Rr | opt. | PLAY, RECORD |
| Session | Rr | req. | All but SETUP, OPTIONS |
| Server | r | opt. | all |
| Speed | Rr | opt. | PLAY |
| Transport | Rr | req. | SETUP |
| Unsupported | r | req. | all |
| User-Agent | R | opt. | all |
| Via | g | opt. | all |
| WWW-Authenticate | r | opt. | all |
Type "g" designates general request headers to be found in both requests and responses, type "R" designates request headers, type "r" designates response headers, and type "e" designates entity header fields. Fields marked with "req." in the column labeled "support" MUST be implemented by the recipient for a particular method, while fields marked "opt." are optional. Note that not all fields marked "req." will be sent in every request of this type. The "req." means only that client (for response headers) and server (for request headers) MUST implement the fields. The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body.
Related protocols: UDP, TCP, HTTP, S-HTTP, RTP
Sponsor Source: RTSP is defined by IETF (http://www.ietf.org) in RFC 2326.
Reference: http://www.javvin.com/protocol/rfc2326.pdf: Real Time Streaming Protocol