Network Working Group H. Schulzrinne
`Request for Comments: 2326 Columbia U.
`Category: Standards Track A. Rao
` Netscape
` R. Lanphier
` RealNetworks
` April 1998
`
` Real Time Streaming Protocol (RTSP)
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`
` The Real Time Streaming Protocol, or RTSP, is an application-level
` protocol for control over the delivery of data with real-time
` properties. 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. This protocol 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 based upon RTP (RFC 1889).
`
`Table of Contents
`
` * 1 Introduction ................................................. 5
` + 1.1 Purpose ............................................... 5
` + 1.2 Requirements .......................................... 6
` + 1.3 Terminology ........................................... 6
` + 1.4 Protocol Properties ................................... 9
` + 1.5 Extending RTSP ........................................ 11
` + 1.6 Overall Operation ..................................... 11
` + 1.7 RTSP States ........................................... 12
` + 1.8 Relationship with Other Protocols ..................... 13
` * 2 Notational Conventions ....................................... 14
` * 3 Protocol Parameters .......................................... 14
` + 3.1 RTSP Version .......................................... 14
`
`Schulzrinne, et. al. Standards Track [Page 1]
`
`1
`
`NEULION 1024
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` + 3.2 RTSP URL .............................................. 14
` + 3.3 Conference Identifiers ................................ 16
` + 3.4 Session Identifiers ................................... 16
` + 3.5 SMPTE Relative Timestamps ............................. 16
` + 3.6 Normal Play Time ...................................... 17
` + 3.7 Absolute Time ......................................... 18
` + 3.8 Option Tags ........................................... 18
` o 3.8.1 Registering New Option Tags with IANA .......... 18
` * 4 RTSP Message ................................................. 19
` + 4.1 Message Types ......................................... 19
` + 4.2 Message Headers ....................................... 19
` + 4.3 Message Body .......................................... 19
` + 4.4 Message Length ........................................ 20
` * 5 General Header Fields ........................................ 20
` * 6 Request ...................................................... 20
` + 6.1 Request Line .......................................... 21
` + 6.2 Request Header Fields ................................. 21
` * 7 Response ..................................................... 22
` + 7.1 Status-Line ........................................... 22
` o 7.1.1 Status Code and Reason Phrase .................. 22
` o 7.1.2 Response Header Fields ......................... 26
` * 8 Entity ....................................................... 27
` + 8.1 Entity Header Fields .................................. 27
` + 8.2 Entity Body ........................................... 28
` * 9 Connections .................................................. 28
` + 9.1 Pipelining ............................................ 28
` + 9.2 Reliability and Acknowledgements ...................... 28
` * 10 Method Definitions .......................................... 29
` + 10.1 OPTIONS .............................................. 30
` + 10.2 DESCRIBE ............................................. 31
` + 10.3 ANNOUNCE ............................................. 32
` + 10.4 SETUP ................................................ 33
` + 10.5 PLAY ................................................. 34
` + 10.6 PAUSE ................................................ 36
` + 10.7 TEARDOWN ............................................. 37
` + 10.8 GET_PARAMETER ........................................ 37
` + 10.9 SET_PARAMETER ........................................ 38
` + 10.10 REDIRECT ............................................ 39
` + 10.11 RECORD .............................................. 39
` + 10.12 Embedded (Interleaved) Binary Data .................. 40
` * 11 Status Code Definitions ..................................... 41
` + 11.1 Success 2xx .......................................... 41
` o 11.1.1 250 Low on Storage Space ...................... 41
` + 11.2 Redirection 3xx ...................................... 41
` + 11.3 Client Error 4xx ..................................... 42
` o 11.3.1 405 Method Not Allowed ........................ 42
` o 11.3.2 451 Parameter Not Understood .................. 42
` o 11.3.3 452 Conference Not Found ...................... 42
`
`Schulzrinne, et. al. Standards Track [Page 2]
`
`2
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` o 11.3.4 453 Not Enough Bandwidth ...................... 42
` o 11.3.5 454 Session Not Found ......................... 42
` o 11.3.6 455 Method Not Valid in This State ............ 42
` o 11.3.7 456 Header Field Not Valid for Resource ....... 42
` o 11.3.8 457 Invalid Range ............................. 43
` o 11.3.9 458 Parameter Is Read-Only .................... 43
` o 11.3.10 459 Aggregate Operation Not Allowed .......... 43
` o 11.3.11 460 Only Aggregate Operation Allowed ......... 43
` o 11.3.12 461 Unsupported Transport .................... 43
` o 11.3.13 462 Destination Unreachable .................. 43
` o 11.3.14 551 Option not supported ..................... 43
` * 12 Header Field Definitions .................................... 44
` + 12.1 Accept ............................................... 46
` + 12.2 Accept-Encoding ...................................... 46
` + 12.3 Accept-Language ...................................... 46
` + 12.4 Allow ................................................ 46
` + 12.5 Authorization ........................................ 46
` + 12.6 Bandwidth ............................................ 46
` + 12.7 Blocksize ............................................ 47
` + 12.8 Cache-Control ........................................ 47
` + 12.9 Conference ........................................... 49
` + 12.10 Connection .......................................... 49
` + 12.11 Content-Base ........................................ 49
` + 12.12 Content-Encoding .................................... 49
` + 12.13 Content-Language .................................... 50
` + 12.14 Content-Length ...................................... 50
` + 12.15 Content-Location .................................... 50
` + 12.16 Content-Type ........................................ 50
` + 12.17 CSeq ................................................ 50
` + 12.18 Date ................................................ 50
` + 12.19 Expires ............................................. 50
` + 12.20 From ................................................ 51
` + 12.21 Host ................................................ 51
` + 12.22 If-Match ............................................ 51
` + 12.23 If-Modified-Since ................................... 52
` + 12.24 Last-Modified........................................ 52
` + 12.25 Location ............................................ 52
` + 12.26 Proxy-Authenticate .................................. 52
` + 12.27 Proxy-Require ....................................... 52
` + 12.28 Public .............................................. 53
` + 12.29 Range ............................................... 53
` + 12.30 Referer ............................................. 54
` + 12.31 Retry-After ......................................... 54
` + 12.32 Require ............................................. 54
` + 12.33 RTP-Info ............................................ 55
` + 12.34 Scale ............................................... 56
` + 12.35 Speed ............................................... 57
` + 12.36 Server .............................................. 57
`
`Schulzrinne, et. al. Standards Track [Page 3]
`
`3
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` + 12.37 Session ............................................. 57
` + 12.38 Timestamp ........................................... 58
` + 12.39 Transport ........................................... 58
` + 12.40 Unsupported ......................................... 62
` + 12.41 User-Agent .......................................... 62
` + 12.42 Vary ................................................ 62
` + 12.43 Via ................................................. 62
` + 12.44 WWW-Authenticate .................................... 62
` * 13 Caching ..................................................... 62
` * 14 Examples .................................................... 63
` + 14.1 Media on Demand (Unicast) ............................ 63
` + 14.2 Streaming of a Container file ........................ 65
` + 14.3 Single Stream Container Files ........................ 67
` + 14.4 Live Media Presentation Using Multicast .............. 69
` + 14.5 Playing media into an existing session ............... 70
` + 14.6 Recording ............................................ 71
` * 15 Syntax ...................................................... 72
` + 15.1 Base Syntax .......................................... 72
` * 16 Security Considerations ..................................... 73
` * A RTSP Protocol State Machines ................................. 76
` + A.1 Client State Machine .................................. 76
` + A.2 Server State Machine .................................. 77
` * B Interaction with RTP ......................................... 79
` * C Use of SDP for RTSP Session Descriptions ..................... 80
` + C.1 Definitions ........................................... 80
` o C.1.1 Control URL .................................... 80
` o C.1.2 Media streams .................................. 81
` o C.1.3 Payload type(s) ................................ 81
` o C.1.4 Format-specific parameters ..................... 81
` o C.1.5 Range of presentation .......................... 82
` o C.1.6 Time of availability ........................... 82
` o C.1.7 Connection Information ......................... 82
` o C.1.8 Entity Tag ..................................... 82
` + C.2 Aggregate Control Not Available ....................... 83
` + C.3 Aggregate Control Available ........................... 83
` * D Minimal RTSP implementation .................................. 85
` + D.1 Client ................................................ 85
` o D.1.1 Basic Playback ................................. 86
` o D.1.2 Authentication-enabled ......................... 86
` + D.2 Server ................................................ 86
` o D.2.1 Basic Playback ................................. 87
` o D.2.2 Authentication-enabled ......................... 87
` * E Authors’ Addresses ........................................... 88
` * F Acknowledgements ............................................. 89
` * References ..................................................... 90
` * Full Copyright Statement ....................................... 92
`
`Schulzrinne, et. al. Standards Track [Page 4]
`
`4
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
`1 Introduction
`
`1.1 Purpose
`
` 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. It does not typically deliver the
` continuous streams itself, although interleaving of the continuous
` media stream with the control stream is possible (see Section 10.12).
` In other words, RTSP acts as a "network remote control" for
` multimedia servers.
`
` The set of streams to be controlled is defined by a presentation
` description. This memorandum does not define a format for a
` presentation description.
`
` 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 [1], but the operation of
` RTSP does not depend on the transport mechanism used to carry
` continuous media. The protocol is intentionally similar in syntax
` and operation to HTTP/1.1 [2] 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. (There is an
` exception to this.)
` * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
` consistent with current HTML internationalization efforts [3].
` * The Request-URI always contains the absolute URI. Because of
` backward compatibility with a historical blunder, HTTP/1.1 [2]
` carries only the absolute path in the request and puts the host
` name in a separate header field.
`
` This makes "virtual hosting" easier, where a single host with one
` IP address hosts several document trees.
`
`Schulzrinne, et. al. Standards Track [Page 5]
`
`5
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` 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. If the presentation is being multicast, the
` presentation description contains the multicast addresses and
` ports to be used for the continuous media. If the presentation
` is to be sent only to the client via unicast, the client
` provides the destination for security reasons.
`
` 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. This
` mode is useful for distributed teaching applications. Several
` parties in the conference may take turns "pushing the remote
` control buttons."
`
` 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.
`
` RTSP requests may be handled by proxies, tunnels and caches as in
` HTTP/1.1 [2].
`
`1.2 Requirements
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in RFC 2119 [4].
`
`1.3 Terminology
`
` Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not
` listed here are defined as in HTTP/1.1.
`
` Aggregate control:
` The control of the multiple streams using a single timeline by
` the server. For audio/video feeds, this means that the client
` may issue a single play or pause message to control both the
` audio and video feeds.
`
` Conference:
` a multiparty, multimedia presentation, where "multi" implies
` greater than or equal to one.
`
`Schulzrinne, et. al. Standards Track [Page 6]
`
`6
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` Client:
` The client requests continuous media data from the media
` server.
`
` Connection:
` A transport layer virtual circuit established between two
` programs for the purpose of communication.
`
` Container file:
` A file which may contain multiple media streams which often
` comprise a presentation when played together. RTSP servers may
` offer aggregate control on these files, though the concept of
` a container file is not embedded in the protocol.
`
` Continuous media:
` Data where there is a timing relationship between source and
` sink; that is, the sink must reproduce the timing relationship
` that existed at the source. The most common examples of
` continuous media are audio and motion video. Continuous media
` can be real-time (interactive), where there is a "tight"
` timing relationship between source and sink, or streaming
` (playback), where the relationship is less strict.
`
` Entity:
` The information transferred as the payload of a request or
` response. An entity consists of metainformation in the form of
` entity-header fields and content in the form of an entity-
` body, as described in Section 8.
`
` Media initialization:
` Datatype/codec specific initialization. This includes such
` things as clockrates, color tables, etc. Any transport-
` independent information which is required by a client for
` playback of a media stream occurs in the media initialization
` phase of stream setup.
`
` Media parameter:
` Parameter specific to a media type that may be changed before
` or during stream playback.
`
` Media server:
` The server providing playback or recording services for one or
` more media streams. Different media streams within a
` presentation may originate from different media servers. A
` media server may reside on the same or a different host as the
` web server the presentation is invoked from.
`
`Schulzrinne, et. al. Standards Track [Page 7]
`
`7
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` Media server indirection:
` Redirection of a media client to a different media server.
`
` (Media) stream:
` A single media instance, e.g., an audio stream or a video
` stream as well as a single whiteboard or shared application
` group. When using RTP, a stream consists of all RTP and RTCP
` packets created by a source within an RTP session. This is
` equivalent to the definition of a DSM-CC stream([5]).
`
` Message:
` The basic unit of RTSP communication, consisting of a
` structured sequence of octets matching the syntax defined in
` Section 15 and transmitted via a connection or a
` connectionless protocol.
`
` Participant:
` Member of a conference. A participant may be a machine, e.g.,
` a media record or playback server.
`
` Presentation:
` A set of one or more streams presented to the client as a
` complete media feed, using a presentation description as
` defined below. In most cases in the RTSP context, this implies
` aggregate control of those streams, but does not have to.
`
` Presentation description:
` A presentation description contains information about one or
` more media streams within a presentation, such as the set of
` encodings, network addresses and information about the
` content. Other IETF protocols such as SDP (RFC 2327 [6]) use
` the term "session" for a live presentation. The presentation
` description may take several different formats, including but
` not limited to the session description format SDP.
`
` Response:
` An RTSP response. If an HTTP response is meant, that is
` indicated explicitly.
`
` Request:
` An RTSP request. If an HTTP request is meant, that is
` indicated explicitly.
`
` RTSP session:
` A complete RTSP "transaction", e.g., the viewing of a movie.
` A session typically consists of a client setting up a
` transport mechanism for the continuous media stream (SETUP),
` starting the stream with PLAY or RECORD, and closing the
`
`Schulzrinne, et. al. Standards Track [Page 8]
`
`8
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` stream with TEARDOWN.
`
` Transport initialization:
` The negotiation of transport information (e.g., port numbers,
` transport protocols) between the client and the server.
`
`1.4 Protocol Properties
`
` RTSP has the following properties:
`
` Extendable:
` New methods and parameters can be easily added to RTSP.
`
` Easy to parse:
` RTSP can be parsed by standard HTTP or MIME parsers.
`
` Secure:
` RTSP re-uses web security mechanisms. All HTTP authentication
` mechanisms such as basic (RFC 2068 [2, Section 11.1]) and
` digest authentication (RFC 2069 [8]) are directly applicable.
` One may also reuse transport or network layer security
` mechanisms.
`
` Transport-independent:
` RTSP may use either an unreliable datagram protocol (UDP) (RFC
` 768 [9]), a reliable datagram protocol (RDP, RFC 1151, not
` widely used [10]) or a reliable stream protocol such as TCP
` (RFC 793 [11]) as it implements application-level reliability.
`
` Multi-server capable:
` Each media stream within a presentation can reside on a
` different server. The client automatically establishes several
` concurrent control sessions with the different media servers.
` Media synchronization is performed at the transport level.
`
` Control of recording devices:
` The protocol can control both recording and playback devices,
` as well as devices that can alternate between the two modes
` ("VCR").
`
` Separation of stream control and conference initiation:
` Stream control is divorced from inviting a media server to a
` conference. The only requirement is that the conference
` initiation protocol either provides or can be used to create a
` unique conference identifier. In particular, SIP [12] or H.323
` [13] may be used to invite a server to a conference.
`
`Schulzrinne, et. al. Standards Track [Page 9]
`
`9
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` Suitable for professional applications:
` RTSP supports frame-level accuracy through SMPTE time stamps
` to allow remote digital editing.
`
` Presentation description neutral:
` The protocol does not impose a particular presentation
` description or metafile format and can convey the type of
` format to be used. However, the presentation description must
` contain at least one RTSP URI.
`
` Proxy and firewall friendly:
` The protocol should be readily handled by both application and
` transport-layer (SOCKS [14]) firewalls. A firewall may need to
` understand the SETUP method to open a "hole" for the UDP media
` stream.
`
` HTTP-friendly:
` Where sensible, RTSP reuses HTTP concepts, so that the
` existing infrastructure can be reused. This infrastructure
` includes PICS (Platform for Internet Content Selection
` [15,16]) for associating labels with content. However, RTSP
` does not just add methods to HTTP since the controlling
` continuous media requires server state in most cases.
`
` Appropriate server control:
` If a client can start a stream, it must be able to stop a
` stream. Servers should not start streaming to clients in such
` a way that clients cannot stop the stream.
`
` Transport negotiation:
` The client can negotiate the transport method prior to
` actually needing to process a continuous media stream.
`
` Capability negotiation:
` If basic features are disabled, there must be some clean
` mechanism for the client to determine which methods are not
` going to be implemented. This allows clients to present the
` appropriate user interface. For example, if seeking is not
` allowed, the user interface must be able to disallow moving a
` sliding position indicator.
`
` An earlier requirement in RTSP was multi-client capability.
` However, it was determined that a better approach was to make sure
` that the protocol is easily extensible to the multi-client
` scenario. Stream identifiers can be used by several control
` streams, so that "passing the remote" would be possible. The
` protocol would not address how several clients negotiate access;
` this is left to either a "social protocol" or some other floor
`
`Schulzrinne, et. al. Standards Track [Page 10]
`
`10
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` control mechanism.
`
`1.5 Extending RTSP
`
` Since not all media servers have the same functionality, media
` servers by necessity will support different sets of requests. For
` example:
`
` * A server may only be capable of playback thus has no need to
` support the RECORD request.
` * A server may not be capable of seeking (absolute positioning) if
` it is to support live events only.
` * Some servers may not support setting stream parameters and thus
` not support GET_PARAMETER and SET_PARAMETER.
`
` A server SHOULD implement all header fields described in Section 12.
`
` It is up to the creators of presentation descriptions not to ask the
` impossible of a server. This situation is similar in HTTP/1.1 [2],
` where the methods described in [H19.6] are not likely to be supported
` across all servers.
`
` RTSP can be extended in three ways, listed here in order of the
` magnitude of changes supported:
`
` * Existing methods can be extended with new parameters, as long as
` these parameters can be safely ignored by the recipient. (This is
` equivalent to adding new parameters to an HTML tag.) If the
` client needs negative acknowledgement when a method extension is
` not supported, a tag corresponding to the extension may be added
` in the Require: field (see Section 12.32).
` * New methods can be added. If the recipient of the message does
` not understand the request, it responds with error code 501 (Not
` implemented) and the sender should not attempt to use this method
` again. A client may also use the OPTIONS method to inquire about
` methods supported by the server. The server SHOULD list the
` methods it supports using the Public response header.
` * A new version of the protocol can be defined, allowing almost all
` aspects (except the position of the protocol version number) to
` change.
`
`1.6 Overall Operation
`
` Each presentation and media stream may be identified by an RTSP URL.
` The overall presentation and the properties of the media the
` presentation is made up of are defined by a presentation description
` file, the format of which is outside the scope of this specification.
` The presentation description file may be obtained by the client using
`
`Schulzrinne, et. al. Standards Track [Page 11]
`
`11
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` HTTP or other means such as email and may not necessarily be stored
` on the media server.
`
` For the purposes of this specification, a presentation description is
` assumed to describe one or more presentations, each of which
` maintains a common time axis. For simplicity of exposition and
` without loss of generality, it is assumed that the presentation
` description contains exactly one such presentation. A presentation
` may contain several media streams.
`
` The presentation description file contains a description of the media
` streams making up the presentation, including their encodings,
` language, and other parameters that enable the client to choose the
` most appropriate combination of media. In this presentation
` description, each media stream that is individually controllable by
` RTSP is identified by an RTSP URL, which points to the media server
` handling that particular media stream and names the stream stored on
` that server. Several media streams can be located on different
` servers; for example, audio and video streams can be split across
` servers for load sharing. The description also enumerates which
` transport methods the server is capable of.
`
` Besides the media parameters, the network destination address and
` port need to be determined. Several modes of operation can be
` distinguished:
`
` Unicast:
` The media is transmitted to the source of the RTSP request,
` with the port number chosen by the client. Alternatively, the
` media is transmitted on the same reliable stream as RTSP.
`
` Multicast, server chooses address:
` The media server picks the multicast address and port. This is
` the typical case for a live or near-media-on-demand
` transmission.
`
` Multicast, client chooses address:
` If the server is to participate in an existing multicast
` conference, the multicast address, port and encryption key are
` given by the conference description, established by means
` outside the scope of this specification.
`
`1.7 RTSP States
`
` RTSP controls a stream which may be sent via a separate protocol,
` independent of the control channel. For example, RTSP control may
` occur on a TCP connection while the data flows via UDP. Thus, data
` delivery continues even if no RTSP requests are received by the media
`
`Schulzrinne, et. al. Standards Track [Page 12]
`
`12
`
`

`

`
`RFC 2326 Real Time Streaming Protocol April 1998
`
` server. Also, during its lifetime, a single media stream may be
` controlled by RTSP requests issued sequentially on different TCP
` connections. Therefore, the server needs to maintain "session state"
` to be able to correlate RTSP requests with a stream. The state
` transitions are described in Section A.
`
` Many method