HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:11:51 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 27 Nov 1996 00:20:00 GMT ETag: "361b7a-12248-329b8930" Accept-Ranges: bytes Content-Length: 74312 Connection: close Content-Type: text/plain INTERNET-DRAFT Anup Rao, Netscape Communications Rob Lanphier, Progressive Networks SUBMITTED: 26th November 1996 Expires: 26th May 1997 Real Time Streaming Protocol (RTSP) STATUS OF THIS MEMO This is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "lid-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au (Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West Coast). Prior to the expiration of this draft, the list of open issues may be found at the following URL: http://www.prognet.com/prognet/ra/openissues.html This contains a list of issues that have been discussed on the MMUSIC mailing list (confctrl). Many of the points brought up have a rather holistic effect on the whole document (such as discussions of converting the protocol to a text-based protocol, or breaking this draft up into several drafts), while other have rather localized effect (Appendix C changes). The points that are localized will be be pointed out in various parts of this draft. 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 delivery mechanisms based upon RTP (RFC 1889). RTSP uses the Session Control Protocol (SCP) (see appendix) to allow the use of a single TCP connection between the client and server for controlling delivery of one or more streams of data. Rao, Lanphier Page 1 INTERNET-DRAFT RTSP November 26, 1996 [Note: see "Use Of UDP For Delivery Of Control Messages" in the "Open Issues" document for discussion of alternative control delivery (http://www.prognet.com/prognet/rt/openissues.html)] TABLE OF CONTENTS 1.0 INTRODUCTION 2.0 DOCUMENT CONVENTIONS 3.0 PROTOCOL DESCRIPTION 3.1 Connection Messages 3.2 Object Messages 3.3 Custom Messages/Events 3.4 Media specific options and Extension mechanism 4.0 EXAMPLES/APPLICATION NOTE 5.0 REFERENCES 6.0 APPENDIXES 6.1 Appendix A - Data Packets 6.2 Appendix B - Session Control Protocol (SCP) 6.3 Appendix C - RTSP Audio Format 6.4 Appendix D - RTSP Audio Annotations 6.5 Appendix E - Authors 1.0 INTRODUCTION This document describes the Real Time Streaming Protocol, or RTSP. The RTSP provides mechanisms to: -Request delivery of real-time data -Request a specific transport type and destination for the delivery of the data -Request information about the data in a format- specific fashion -Start, stop, and pause the delivery of the data -Provide random access to various portions of the data (where applicable) RTSP uses TCP for delivery of control messages, and allows for a variety of delivery options for the data including both multicast and unicast UDP based on RTP(RFC 1889), and TCP where applicable. RTSP uses the Session Control Protocol (see appendix) to allow the use of a single TCP connection between the client and server for controlling delivery of one or more streams of data. The RTSP specifically uses one SCP session to deliver control messages and in addition, a new SCP session might be opened for each real-time object delivered. Rao, Lanphier Page 2 INTERNET-DRAFT RTSP November 26, 1996 While the protocol is designed for the streaming of real- time data regardless of its format, it also provides mechanisms to inquire about format specific information (compression type, data rate, compression-type specific headers and frame boundaries). Considerations for each peer arising from these features are discussed later in the document. Three typical categories of data whose delivery could be controlled with RTSP include: 1. Real-time stored clips This category comprises all real-time recordings (primarily audio/video). Examples include web sites with audio narration, stored audio recordings, and video recordings. A typical end-user application would be an audio/video store site providing excerpts from its collection on-demand. 2. Real-time live feeds This category comprises real-time data which is fed in live at the server site rather than being pre-recorded. Examples of this usage include a press conference, a live internet radio station, or a televised shuttle launch. 3. Non real-time stored data This category comprises non-real-time data of any MIME type, similar to data served by HTTP servers. This data is provided over a new SCP session. While HTTP servers would serve this kind of data in most cases, it might be advanta- geous to serve non-real-time data with RTSP. This is typically true of non-real-time data pertaining to real- time data being served; for example, a text track playing along with audio/video. This category is meant to provide the capability of serving non-real-time data through RTSP, and it is strongly recommended that it be used only when advantageous over existing mechanisms. [Note: Other scenarios that don't fall into the above categories may be discussed in the "Open Issues" document (http://www.prognet.com/prognet/rt/openissues.html)] 2.0 DOCUMENT CONVENTIONS The following conventions are used throughout this document: Byte Order and Alignment All integer fields are carried in network byte order, where the most significant byte is sent first. Integers are aligned on their natural length: 16 bit integers on even byte boundary, 32 bit integers on 4 byte boundary and so on. Rao, Lanphier Page 3 INTERNET-DRAFT RTSP November 26, 1996 Definitions Stream A stream is data of a distinct type that is sent from server to client at a rate defined by the server, even if more bandwidth is available. For a typical video broadcast, for example, one stream could consist of the video signal, one stream could consist of the audio data, and one stream could contain the closed caption information. In most cases, each stream is served at the rate that it should be rendered by the client. Global Control Session The SCP session with a well-known session ID, used for exchange of connection messages described later in this document. Stream Control Session An SCP session established for each stream, used for exchange of object messages described later in this document. URL A Uniform Resource Locator or URL is a unique identifier that describes a resource on the Internet. The syntax for URLs is defined by RFC 1738. 3.0 PROTOCOL DESCRIPTION Two classes of messages exist in RTSP; those sent on the Global control session, termed connection messages and those sent on the Stream control session, termed object messages. Some messages might fall in both categories. 3.1 Connection messages Connection messages are used to negotiate protocol version and possibly client identity. This is common to all streams requested on the connection. Rao, Lanphier Page 4 INTERNET-DRAFT RTSP November 26, 1996 HELLO Upon connection, the client sends a HELLO message to the server informing it of its version and desire to establish a RTSP session. The server replies with a HELLO message. The server need not wait for the clients HELLO message before sending its own. The message includes protocol version, and optional character string denoting the user- agent(to be specified). The communication continues in the lower of the exchanged versions. If the two sides cannot speak this common version, the connection is closed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major | Minor | Sub Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / User Agent (Optional) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Major Version Specifies the major RTSP version. Minor Version Specifies the minor RTSP version within the major version. Sub Protocol Specifies the sub-protocol spoken by the sender. For normal client-server communication, this should be 0. Reserved For future use. User Agent Is an optional null-terminated character string sent by the client to provide information like the client name, machine type, OS etc. Rao, Lanphier Page 5 INTERNET-DRAFT RTSP November 26, 1996 ID This message is sent by either a server or a client. The recipient of this message is asked to prove its identity. A number of different schemes are possible, the simplest of which uses a password. More complicated schemes can cause a one time challenge and response mechanism. Multiple challenge response steps are possible and implemenation dependent. A separate ID message allows a server to service a number of different classes of users. The ID message can be sent at any time during the session or may be sent once per URL, depending on how a service is configured. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key type | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / authentication key / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key type Specifies the authentication key type. Authentication of different strengths might be required in different situations. This field allows a choice of authentication. It is up to the client and server to negotiate what level of authentication is used. Note that different services might be available at different authentication levels. Authentication key Specifies the key that authenticates the sender. The standard key types and proper responses will be specified in an extension to this document. ID_RESP This message is sent in response to an ID message. The entity issuing the ID message closes the TCP connection if the response is not valid. Rao, Lanphier Page 6 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(ID_RESP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key type | response code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / response data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key type Specifies the authentication key type. Authentication of different strength may be required in different situations. This field allows a choice of authentication. It is up to the client and server to negotiate what level of authentication is used. Note that different services might be available at different authentication levels. Response code Specifies one of the two possible responses to an ID message: OK Authentication type recognized, response follows. UNKNOWN Unknown type, ordered list of authentication types follows (can be a null list). Response data Specifies the response, depending on the response code. If OK, then this is the key that authenticates the sender, and the format is dictated by the authentication type. If UNKNOWN, then this is a list of 16-bit response types that are acceptable to the recipient. The standard key types and proper responses will be specified in an extension to this document. REDIRECT A redirect message informs the client that it must connect to another server location. When received on the Global control session, it should be made effective as specified by offset. The message can also be sent on a Stream control session, in which case it it relative to the stream. Rao, Lanphier Page 7 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (REDIRECT) | +-------------------------------+-------------------------------+ | Offset | +-------------------------------+-------------------------------+ | | / URL / | | +-------------------------------+-------------------------------+ Offset On the Stream control session, specifies the position (in milliseconds) in the media stream at which time the redirection is effective. If received on the global control session, it means that the server is not available after this time. URL Is a null-terminated string that identifies the new location for the object. This URL is similar to the one specified in the original FETCH request, described later in this document. OPTIONS This message is used to negotiate additional functionality. This can be sent by the client or the server. This is provided as an extension mechanism to extend the protocol without changing the version number. Set 0 refers to the global set of options, a universally-agreed upon set. Implementors can use this to negotiate replacements for messages in the current specification; however, all implementations must be able to support the core messages defined here, and be prepared not to use an option should the other implementation not be prepared to support the given option. The maximum size of an option set is 64. This is defined in the spirit of the TELNET protocol (RFC 854), which provides a further explanation of how different implementations may interoperate using this mechanism. Rao, Lanphier Page 8 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag (OPTIONS) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option set | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | highest option number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option set Implementors can specify an option set to use for adding custom extensions. In addition, as the protocol matures, certain options may be accepted as universal to all clients,which will be placed in the reserved range of option sets. The following ranges of options are reserved: Option set Purpose ----------- ------------------------------------ 0 This is a universally accepted set of options 0x1-0xFFFF Reserved for later allocation 0x10000-0xFFFFFFFF Custom extensions (i.e. vendor or organization specific) Highest option number Specifies the highest option number that is set or unset. It is used to calculate the length of the bit vectors that follow. This list is zero indexed. Rao, Lanphier Page 9 INTERNET-DRAFT RTSP November 26, 1996 s.d.s.w s.d.s.w ^ ^ ^ ^ | | | | select do/don't ----------+ | | | do/don't -------------------+ | | select will/won't ------------+ | will/won't ---------------------+ select do/don't If set, activates the do/don't flag do/don't If set to 1, means DO and if set to 0, means DON'T. DO indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option. DON'T indicates the demand that the other party stops performing, or confirmation that you are no longer expecting the other party to perform, the indicated option. select will/won't If set, activates the will/won't flag will/won't 1 means WILL, 0 means WON'T. WILL indicates the desire to begin performing, or confirmation that the indicated options are being used. WON'T indicates the refusal to perform, or continue performing, the indicated option. At a minimum, the response to a OPTION is to reply with the desire to perform NONE of the requested options. The Working Group or IETF needs to define and regulate the registration process for OPTIONS sets. Currently, no sets are defined. GOODBYE Sent only by the client to politely close the RTSP session. Rao, Lanphier Page 10 INTERNET-DRAFT RTSP November 26, 1996 The client sends this message to the server to indicate that it is done with its requests and wants to terminate the session. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (GOODBYE) | +-------------------------------+-------------------------------+ 3.2 OBJECT MESSAGES These messages are sent on the stream control session (one of which exists for each stream). They a used to request objects, set transport mechanism, and control data delivery. FETCH This is the first message sent on a new stream control session. It requests an object of a given name. If the object exists, and the client is permitted to access it, the server accepts the request and sends a STREAM_HEADER message to the client. If the object is non-existent or access is not allowed, the appro- priate error message is sent to the client. The client uses this message to request an object (for example, an audio clip) from the server. The object is specified as an URL. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (FETCH) | +-------------------------------+-------------------------------+ | Bandwidth (Bits per second) | +-------------------------------+-------------------------------+ | Max Number of Hops | Request Flags |F|M|N| +-------------------------------+-------------------------------+ | | / URL (null-terminated) / | | +-------------------------------+-------------------------------+ Bandwidth Specifies the client's estimate of the bandwidth (in bits per sec) it has available for a particular stream. The exact bit rate of the stream is provided by the STREAM_HEADER message from the server. If the server refuses the request based on insufficient bandwidth, then the server sends the appropriate error message. Rao, Lanphier Page 11 INTERNET-DRAFT RTSP November 26, 1996 Max Number of Hops Specifies the maximum number of hops. A hop is a connection between Client, Server or Proxy. For example, the are three hops for passing through two proxies and connecting to a server. If set to 0xFFFF, then the number of hops is unlimited. Request Flags F - Fresh bit, used to override Proxy Cache M - Multicast capable N - No Rate (rate unlimited file transfer, used only for TCP. This could be used for transfering non-real time data, such as metafiles) URL - Universal Resource Locator Specifies a null-terminated string which identifies the location for the object (i.e. RTSP://host-name:port/filename) STREAM_HEADER This message is sent in response to a successful FETCH message. It provides the basic information about the stream such as rate, generic type, and last modification time. Rao, Lanphier Page 12 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (STREAM_HEADER) | +-------------------------------+-------------------------------+ | Generic Type (family) | +-------------------------------+-------------------------------+ | Bit Rate (Bits per second) | +-------------------------------+-------------------------------+ | Last Modification Time | +-------------------------------+-------------------------------+ | Reserved | +-------------------------------+-------------------------------+ | Length (milliseconds) | +-------------------------------+-------------------------------+ | Max Packet size (bytes) | +---------------+---------------+---------------+---------------+ | Flags x|L|C|H|A|U|M| +---------------+---------------+---------------+---------------+ Generic type (family) Specifies the type of family, such as RTSP_Audio, etc. Currently, RTSP_Audio is defined in the appendix. Bandwidth Specifies the rate or bandwidth of the stream in bits per second. It is set to 0 if non-realtime. Last Modification Time Specifies the last time the object was modified. The specified time is seconds since Jan 01 1970(UTC). Reserved Reserved for future use. Length Specifies the stream length in miliseconds. It is 0 if the object is live or if it is non-realtime. Max Packet Size Specifies the maximum packet size in bytes that the server supports for the stream. Rao, Lanphier Page 13 INTERNET-DRAFT RTSP November 26, 1996 Flags x: Unicast available L: Live : if set, the stream is live and there is no concept of position. C: Copy : if set, means that the client can save it. H: Cached : if set, the object is cached on a proxy. A: if set, stream can be cached by the client U: UDP Okay : if set, the stream can be sent via a unreliable channel. M: Stream is available via Multicast, and a SET_TRANSPORT message follows providing this information [Note: There has been discussion of providing this information in a session description that is loaded via HTTP or some other mechanism prior to the RTSP connection being established. See "Metafiles/Session Descriptions" in http://www.prognet.com/prognet/rt/openissues.html] SET_TRANSPORT This message is sent to set the delivery mechanism for a stream. The client uses this message to request the transport used for the data transfer. The server can use this message to inform the client about multicast availability (this is the only instance the server sends this message). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag (SET_TRANSPORT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| | ChannelID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= / Transport specific fields / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C flag : This flag specifies the type of header/framing. C = 0 : Standard RTP header C = 1 : Compressed/Extensible RTP header Rao, Lanphier Page 14 INTERNET-DRAFT RTSP November 26, 1996 SSRC: 32 bits Identifies the synchronization source to be associated with the data. This can be used for de-multiplexing by the client of data received on the same port. Channel ID Transport channel Fixed RTP header Compressed RTP header Channel ID Unicast UDP Yes Yes 0 Multicast UDP Yes Yes 1 SCP Yes Yes 2 SCP - compressed Yes Yes 3 Note : The client may not send a channel ID of 1. This is sent by the server only. Transport Spcific Fields Channel ID 0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Specifies the port number on which the stream should be sent. Channel ID 2,3 : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | session ID | (reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Session ID Specifies the SCP session ID that should be associated with this stream. Rao, Lanphier Page 15 INTERNET-DRAFT RTSP November 26, 1996 Channel ID 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port Specifies the port number on which the stream is sent. Address Specifies the multicast group address where the data is available. [Note: There is some debate over the best way to address RTP header compression in the "Compressed RTP section" of the "RTSP Open Issues" document. (see http://www.prognet.com/prognet/rt/openissues.html)] [Note: There has also been debate about what level of RTP support to provide. It has been suggested that a server should be able to stream directly into an RTP based conference which may contain clients that are not necessarily RTSP-aware, so long as the requesting conference client provides control connection proxying. See the "RTSP Open Issues" document section titled "Joining Into Existing Conferences" (http://www.prognet.com/prognet/rt/openissues.html)] SET_SPEED This advisory message sets the speed at which the server delivers data to the client, contingent on the server's ability and desire to serve the file at the given speed. Implementation by the server is optional. The default is the bit rate of the stream. Rao, Lanphier Page 16 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(SET_SPEED ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (reserved) |F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | speed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Speed Send speed as a ratio. The speed is relative to the normal speed for the stream, as expressed as a ratio of speed divided by 65536 (i.e. 2^16). For example, speed is 65536 for real-time delivery, 32768 (2^15) for half-speed delivery, and 131072 (2^17) for double-speed delivery. A speed of zero is invalid. F If F is set, sends the data as fast as possible. This feature only works on a TCP data connection. PLAY_RANGE This message tells the server to start sending data via the previously set transport mechanism. The two fields, From and To, specify the range in milliseconds. If the the "To" field is zero, it signifies the end of the stream. If the "To" field is non- zero, it should be greater than the value specified in the "From" field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (PLAY_RANGE) | +-------------------------------+-------------------------------+ | From (in ms) | +-------------------------------+-------------------------------+ | To (in ms) | +-------------------------------+-------------------------------+ Rao, Lanphier Page 17 INTERNET-DRAFT RTSP November 26, 1996 STREAM_SYNC This message is sent by the server to the client in response to the PLAY_RANGE message. It informs the client of the first expected sequence number, and in case of some delivery types, the first expected timestamp. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (STREAM_SYNC) | +-------------------------------+-------------------------------+ | Sequence Number | Reserved | +-------------------------------+-------------------------------+ | Start Time | +---------------------------------------------------------------+ Sequence Number Specifies where the new data starts. This number should be far enough away from the last sequence number sent so that old packets can be detected and rejected. Start Time Specifies the offset (in milliseconds) relative to the origin of the first packet that will be sent. SET_BLOCK_SIZE This is an advisory message sent from the client to the server setting the transport packet size. The server truncates it to the closest multiple of the minimum media-specific block size or overrides it with the media specific size if necessary. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (SET_BLOCKSIZE) | +-------------------------------+-------------------------------+ | Block Size | +-------------------------------+-------------------------------+ Block Size Specifies the size of the block in bytes. Rao, Lanphier Page 18 INTERNET-DRAFT RTSP November 26, 1996 STOP This messages tells the server to stop sending. This is used for `pause' operation, and the server is to keep track of the stream position in order to `resume' play when a resume command is given. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (STOP) | +-------------------------------+-------------------------------+ RESUME This message tells the server to resume sending from the position it was stopped at with the STOP message. If no STOP message was sent prior to RESUME, the messages is ignored. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (RESUME) | +-------------------------------+-------------------------------+ SEND_REPORT This message is sent by the server to the client requesting statistics on data reception. At a minimum, the client is required to reply to the message of type 1 (PING) indicating that it is receiving data. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (SEND_REPORT) | +-------------------------------+-------------------------------+ | Report Type | +-------------------------------+-------------------------------+ Report Type: 1 - PING, 2 - Text Message 3 - Reception Report REPORT Sent by the client to the server in response to the SEND_REPORT message. or otherwise. Rao, Lanphier Page 19 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (REPORT) | +-------------------------------+-------------------------------+ | Report Type | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Report Specific Fields | +-------------------------------+-------------------------------+ Report Type: 1 - PING 2 - Text Message, 3 - Reception Report PING Report (1) Report Specific Fields (NONE, just respond with Report type 1) Text Message (2) Report Specific Fields 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Text String (Null Terminated) | +-------------------------------+-------------------------------+ Text String (Null terminated). Reception Report (3) - Report specific fields 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Packets Received | Packets Lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lagging | Buffer occupancy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packets Received Specifies the number of packets received since last report Packets Lost Specifies the number of packets lost since the last report. Lagging Specifies that the buffer level is below (1), or above the desired level (0). Rao, Lanphier Page 20 INTERNET-DRAFT RTSP November 26, 1996 Buffer occupancy Specifies the number of milliseconds below or above the desired level. ERROR This message is sent by the server to the client in case of an abnormal condition. It includes a numeric error code which is defined later in this document and an optional null-terminated error string. Error is sent by the server to report an error to the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (ERROR) | +-------------------------------+-------------------------------+ |F| error code | +-------------------------------+-------------------------------+ | | / Error String (null-terminated) / | | +-------------------------------+-------------------------------+ F:(one bit) Fatal Error Flag Is used to tell the client it must terminate the session. error codes: 200 - Success 400 - FETCH failure; no such object exists 401 - FETCH failure; fetch refused 402 - SEND_RANGE out of bounds 403 - Incompatible protocol version 404 - SET_TRANSPORT failure; bad port specified 405 - Feed gone - live feed closed 406 - Can't do that on non-live feed 407 - Request not supported 408 - Request refused due to bandwidth mismatch (e.g. Insufficient Client Bandwidth) 500 - Unspecified server-side problem 501 - Server running low on resources and cannot satisfy request Rao, Lanphier Page 21 INTERNET-DRAFT RTSP November 26, 1996 UDP_RESEND This messages is sent by the client to request retransmission packets of specific sequence numbers. The service of the request at the server end is optional. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | tag (UDP_RESEND) | +-------------------------------+-------------------------------+ | Sequence Number | Number of Packets | +-------------------------------+-------------------------------+ Sequence Number: Specifies the first packet that needs to be resent. Number of Packets: Specifies the number of packets that need to be resent, beginning with the above sequence number. 3.3 CUSTOM MESSAGES/EVENTS These messages are intended to provide a general notification system from the server to the client or from the client to the server. The message could be sent on the control or object session. An example of using the custom message is when the server announces the availability of a new stream, or drives the client's web browser to a particular location. The message includes payload type and payload. Currently, defined payload types are NewURL(1) and GotoURL(2). Implementation of this custom messaging system is optional for both client and server, and vendor specific payload types could be added as necessary. Rao, Lanphier Page 22 INTERNET-DRAFT RTSP November 26, 1996 EVENT_NOTIFY 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(EVENT_NOTIFY) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Payload / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Type Specifies one of the currently defined payload types. For example, NewURL(1) and GotoURL(2). Payload For the previous two payload types, specifies the URL. 3.4 MEDIA SPECIFIC OPTIONS AND EXTENSION MECHANISM RTSP provides an extensible way for the client to query and set media-specific parameters and to set media-specific parameters for the stream. This is done via the GET_PARAM and PARAM_REPLY messages. The GET_PARAM message includes a request ID, family identifier and a parameter identifier. The PARAM_REPLY mes- sage includes the corresponding request ID, and a variable length reply data payload. GET_PARAM 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag (GET_PARAM) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUEST_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FAMILY_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PARAMETER_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rao, Lanphier Page 23 INTERNET-DRAFT RTSP November 26, 1996 REQUEST_ID Is a 32 bit number used to reference this request, must be non- zero. FAMILY_ID Currently, RTSP_Audio (Family 1) is defined in Appendix C. PARAMETER_ID Specified the parameter ID within the family. These are defined for the in Appendix C. PARAM_REPLY 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(PARAM_REPLY) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUEST_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FAMILY_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PARAMETER_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DATA_TYPE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / DATA / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a list of currently defined family and parameter identifiers, see Appendix C. An example of use of these messages is available in the next section. Data types are String(0), Integer(1), and Opaque data(2). This message can be sent by the server to the client, even if the client has not sent a request. The client must be prepared to handle this. In this case, the REQUEST_ID is 0x0. REQUEST_ID Is a 32 bit number used to reference this request, must be non- zero. FAMILY_ID Currently, RTSP_Audio (Family 1) is defined in Appendix C. Rao, Lanphier Page 24 INTERNET-DRAFT RTSP November 26, 1996 PARAMETER_ID Specified the parameter ID within the family. These are defined for the in Appendix C. PARAM_REFUSE If the server does not support the requested parameter or family, it sends a ParamRefuse, whose format is as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag(PARAM_REFUSE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUEST_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FAMILY_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PARAMETER_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR_CODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REQUEST_ID Is a 32 bit number used to reference this request, must be non- zero. FAMILY_ID Currently, RTSP_Audio (FAMILY_ID1) is defined in Appendix C. PARAMETER_ID Specified the parameter ID within the family. Currently, the RTSP_Audio is defined in Appendix C. ERROR_CODE: As defined earlier. SET_PARAM Using the same principle as GET_PARAM, a media-specific option for the stream can be set using the SET_PARAM message. Examples of an option include encryption, custom encoding or quality levels. The server replies with a SET_PARAM_REPLY or PARAM_REFUSE. Rao, Lanphier Page 25 INTERNET-DRAFT RTSP November 26, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag (SET_PARAM) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUEST_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FAMILY_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PARAMETER_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / DATA / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REQUEST_ID Is a 32 bit number used to reference this request, must be non- zero. FAMILY_ID Currently, RTSP_Audio (Family 1) is defined in Appendix C. PARAMETER_ID Specified the parameter ID within the family. These are defined for the in Appendix C. DATA Specifies the payload specific to the family and parameters. Rao, Lanphier Page 26 INTERNET-DRAFT RTSP November 26, 1996 4.0 EXAMPLES/APPLICATION NOTE Example of use of GetParam to request and play an audio file: CLIENT SERVER CONTROL_SCP: HELLO---------------------------> <---------------------------CONTROL_SCP:HELLO <--------------------------- CONTROL_SCP:ID (OPTIONAL) CONTROL_SCP:ID_RESP---------------------> STREAM_SCP_0: FETCH-----------------------------> STREAM_SCP_0: GETPARAM--------------------------> STREAM_SCP_0: GETPARAM--------------------------> <------------------------- STREAM_SCP_0:STREAM_HEADER <------------------------- STREAM_SCP_0:PARAM_REPLY <------------------------- STREAM_SCP_0:PARAM_REPLY STREAM_SCP_0: SETPARAM(eg.encryption) ----------------> <-------------------------- STREAM_SCP_0:PARAM_REPLY STREAM_SCP_0: SET_TRANSPORT(RTP)----------------> STREAM_SCP_0: PLAY_RANGE(a,b)-------------------> <--------------------------- STREAM_SCP_0:STREAM_SYNC <--------------------------- Data on UDP channel Example of use of custom message: CLIENT SERVER CONTROL_SCP: HELLO----------------------------> Rao, Lanphier Page 27 INTERNET-DRAFT RTSP November 26, 1996 <----------------------------CONTROL_SCP:HELLO STREAM_SCP_0: FETCH -------------------> <-------------------------- STREAM_SCP_0:STREAM_HEADER STREAM_OBJECT_SCP_0: SET_TRANSPORT(RTP)--------> STREAM_OBJECT_SCP_0: PLAY_RANGE(a,b)-----------------> <--------------------------- STREAM_SCP_0:STREAMSYNC <--------------------------- Data on UDP channel <--------------------------- CONTROL_SCP: EVENT_NOTIFY(NewURL) STREAM_OBJECT_SCP_1: FETCH---------------------> <------------------------- STREAM_SCP_1:STREAM_HEADER STREAM_SCP_1: SET_TRANSPORT(RTP)----------------> STREAM_SCP_1: SEEK(a,b)-------------------------> <--------------------------------- STREAM_SCP_1:STREAM_SYNC <------------------------------- Data on UDP channel 5.0 REFERENCES: [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: A Transport Protocol for real-time applications." RFC 1889 Rao, Lanphier Page 28 INTERNET-DRAFT RTSP November 26, 1996 [2] Simon Spero, Session Control Protocol(SCP). [3] J. Postel, J. Reynolds, "Telnet Protocol Spefication.", RFC 854 6.0 APPENDIXES 6.1 APPENDIX A - Data packets [Note: see "Compartmentalize the Protocol" in the "RTSP Open Issues" document for discussion of the possible split of this appendix into a separate document (http://www.prognet.com/prognet/rt/openissues.html)] The following are the types of data packet formats. RTP: The format of the UDP packet is a standard RTP packet, as per RFC 1889. This is a description of how the RTP packet is used by RTSP. Complete generalized descriptions of these fields can be found in RFC 1889. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first twelve octets are present in every RTP packet, while the list of CSRC identifiers usually will not be present (though may be used when broadcasting an RTP conferencing session, for instance). The fields have the following meaning: Version (V): 2 bits This field identifies the version of RTP. The version used by this specification is two (2). Rao, Lanphier Page 29 INTERNET-DRAFT RTSP November 26, 1996 Padding (P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored. Extension (X): 1 bit Not used. Set to zero for RTP compatibility. CSRC count (CC): 4 bits. The CSRC count contains the number of CSRC identifiers that follow the fixed header. Marker (M): 1 bit In RTSP, this designates the block boundary. This is a point at which a client can start decoding the stream. Payload type (PT): 7 bits Each stream uses a payload type allocated dynamically between 96 and 127, to remain consistent with the dynamic mappings in the audio-video profile (RFC 1890). Sequence number: 16 bits The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is random (unpredictable) to make known plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does. Timestamp: 32 bits The timestamp is a tick mark which reflects the sampling instant of the first octet in the RTP data packet. The clock frequency is dependent on the format of data carried as payload. SSRC: 32 bits The SSRC field identifies the synchronization source associated with the data. This identifier is chosen with the intent that no two synchronization sources within the same RTSP session will have the same SSRC. CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 may be identified. Rao, Lanphier Page 30 INTERNET-DRAFT RTSP November 26, 1996 Compressed RTP [Note: There has been some questions as to the appropriateness of this name, since it is really an application-level compression that relies on RTSP to carry some of the "compressed" information out of band. We will probably change this name to reflect its distance from RTP.] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |v|M|t|s| SSRC | sequence number |timestamp (opt)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+ version (v): 1 bit If this is 1, the rest of this packet is standard RTP, and we can treat it as such. If it is 0, the rest of the packet is defined as follows. marker (M): 1 bit In RTSP, this designates the block boundary. This is a point at which a client can start decoding the stream. timestamp lower bits compression bit (t): 1 bit This number specifies the existence of the least-significant two bytes of the timestamps. If this bit is not set, the value of these bytes are calculated based some media-specific method (probably using the sequence number). If this bit is set, the value of these bytes are given in this packet. The upper bits are determined based on the probable value given the sequence number. This compression scheme does not work for packets that are spaced out at intervals greater than roughly 64 seconds. sequence number inclusion bit(s) This bit is for compatibility with reliable, sequenced delivery mechanisms, such as SCP. This should always be set to 1. SSRC: 4 bits or 36 bits The SSRC field identifies the synchronization source associated with the data. This identifier is chosen with the intent that no two synchronization sources within the same RTSP session will have the same SSRC. Rao, Lanphier Page 31 INTERNET-DRAFT RTSP November 26, 1996 This is 4 bits unless set to 15 (1111), in which case it expands to 36 bits, and the lower 32 bits are the actual SSRC. sequence number: 16 bits The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt, because the packets may flow through a translator that does. 6.2 APPENDIX B - Session Control Protocol (SCP) [Note: see "Compartmentalize the Protocol" in the "RTSP Open Issues" document for discussion of the possible split of this appendix into a separate document (http://www.prognet.com/prognet/rt/openissues.html)] [Note: other methods of multiplexing are currently being discussed. Simon Spero has a new draft of SCP at http://sunsite.unc.edu/ses/scp.html. SMUX, from Jim Gettys and the W3C at http://www.w3.org is another candidate.] This document was originally written by Simon Spero for the HTTP- NG project. It has been slightly editied and clarified. Several heavily used Internet applications such as FTP, GOPHER, and HTTP use a protocol model in which every transaction requires a separate TCP connection. Since clients normally issue multiple requests to the same server, this model is quite inefficient, as it incurs all the connection start up costs for every single request. SCP is a simple protocol which lets a server and client have multiple conversations over a single TCP connection. Definitions A session is a virtual stream of data carried within the single TCP connection. It is independent of any other session within the same connection. A session identifier is a unique number which is used to specify which session a particular block of data is associated with. Rao, Lanphier Page 32 INTERNET-DRAFT RTSP November 26, 1996 Session flag names are borrowed from TCP. The name SYN means "open" in SCP. The name FIN means "finish" or "close" in SCP. The name RST means "reset" in SCP. PUSH indicates the end of a segment. Services SCP's main service is dialogue control. This service allows either end of the connection to establish multiple virtual sessions over a single transport connection. SCP also allows a sender to indicate message boundaries, and allows a receiver to reject an incoming session. Design goals SCP allows data to be sent with the session establishment; the recepient does not confirm successful connection establishment, but may reject unsuccessful attempts. This simplifies the design of the protocol, and removes the latency required for a con- firmed operation. Low overhead SCP has a fixed overhead of 8 bytes per segment. This overhead is only incurred once per segment, instead of once per packet. Simple design The session protocol should be simple enough to implement for a single application. Rao, Lanphier Page 33 INTERNET-DRAFT RTSP November 26, 1996 Protocol Description Header Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| flags | session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | session length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: 0x1 : SYN 0x2 : FIN 0x4 : RST 0x8 : PUSH Protocol Operation Session ID allocation Each session is allocated a session identifier. Session Identifiers below 1024 are reserved. Session IDs allocated by clients are even; those allocated byservers, odd. Session establishment A new session is established by setting the SYN bit in the first message sent on that channel. Graceful release A session is ended by sending a message with the FIN bit set. Each end of a connection may be closed independently. Disgraceful release A session may be terminated by sending a message with the RST bit set. All pending data for that session should be discarded Message boundaries A message boundary is marked by sending a message with the PUSH bit set. The boundary is set at the final octet in this message, including that octet. Rao, Lanphier Page 34 INTERNET-DRAFT RTSP November 26, 1996 Compressed Header SCP +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ |1|P| IDL | LNL | session ID | segment length | data | +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+ P: 1 bit Push bit. This denotes a message boundry, which is set at the final octet in this message. IDL: 3 bit Length of the session ID field (as described below). LNL: 3 bits Length of the session length field (as described below). session ID: Variable number of bits, depending on IDL field Identifier for this session. The session ID value is relative to 1024, which is the minimum non-reserved value. segment length: Variable number of bits, depending on LNL field. Length of the payload in bytes. IDL and LNL values: 3 bits value Length of Session ID or Segment Length field 0x0 use previous value 0x1 4 bits 0x2 8 bits 0x3 12 bits 0x4 16 bits 0x5 24 bits 0x6 32 bits 0x7 64 bits IDL and LNL values should be chosen so that byte alignment of the packet is guaranteed. 6.3 APPENDIX C - RTSP -Audio (Family ID =1 ) Format descriptor (Parameter=1) [Note: see "Compartmentalize the Protocol" in the "RTSP Open Issues" document for discussion of the possible split of this appendix into a separate document (http://www.prognet.com/prognet/rt/openissues.html)] Rao, Lanphier Page 35 INTERNET-DRAFT RTSP November 26, 1996 [Note: see "Change Appendix C (families of stream types)" in the "RTSP Open Issues" document for discussion of a series of proposed changes to this Appendix, such as changing CODEC IDs to UUIDs, modifying the audio family, and adding a video family (http://www.prognet.com/prognet/rt/openissues.html)] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODEC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumChannels | Bits/Sample | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Samples Per Second | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average Frame Size | Maximum Frame Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Samples Per Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Frames Per Packet | Extra Bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Of Frames | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CODEC-specific Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above structure describes a generic compressed audio stream for the RTSP Audio Family. CODEC ID: The CODEC ID uniquely identifies the codec which was used to generate this audio data. CODEC ID's in the range 0x00 through 0xffff are reserved for ACM (Audio Compression Manager native to Microsoft Windows Operating systems) compatible/ interoperable codecs. NumChannels: Use 1 for mono, 2 for stereo Bits/Sample: Number of bits per sample as specified by the codec. Codecs which do not need or do not have a well defined value for this parameter may set this to zero. Rao, Lanphier Page 36 INTERNET-DRAFT RTSP November 26, 1996 Samples Per Second: Playback rate for each channel in samples per second (hertz). Average Frame Size: Frame is the smallest unit of encoded audio data that can be streamed from the server. Average Frame Size represents the typical size (in bytes) of a frame. This family does not support non byte-aligned frames. Maximum Frame Size: Size in bytes of the largest frame. For constant bit rate codecs, this value is the same as the Average Frame Size. Samples Per Frame: Number of samples of audio data encoded in each frame. This family does not support variable duration frames. P: If P is not set, then the audio data is planar and the client has the option to request data packets of size which are multiples of the average frame size. If P is set, the stream is packetized (usually for variable bit rate data and live feeds), then the size of the data packet is defined by frame size and frames per packet (described below). Frames Per Packet: For packetized formats, this represents the number of frames in every data packet. For planar formats, this is a hint to the client regarding the server preference. Extra Bytes: This specifies the number of bytes of codec specific data that follow the fixed header. Number of Frames: Total number of frames in the audio stream. For non-seekable streams (e.g. live feeds), this should be set to zero. 6.4 APPENDIX D - RTSP - Audio (Family ID =1 ) : Annotations (Parameter=2) [Note: see "Compartmentalize the Protocol" in the "RTSP Open Issues" document for discussion of the possible split of this appendix into a separate document (http://www.prognet.com/prognet/rt/openissues.html)] Rao, Lanphier Page 37 INTERNET-DRAFT RTSP November 26, 1996 This payload data enables the server to communicate additional information about the stream to the client. Examples of such information include the authorof the clip, the clip name, copyright information, creation date etc. The payload data is organized as a list of information chunks. Each such chunk has an identifier, length of the chunk and the actual data itself. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of chunks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Identifier (Chunk 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Bytes (Chunk 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Data (Chunk 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Identifier (Chunk n-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Bytes (Chunk n-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Data (Chunk n-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Identifier This is a four character code identifying the chunk. For example, `I''C''O''P' is used for copyright information which is stored as a null terminated string. `I''N''A''M' is used for the name of the audio clip. `I''U''R''L' serves to pass the URL for the CODEC installer. The client should use this URL if it encounters a clip compressed with an unknown CODEC. Any chunk with an unrecognized four character code should be ignored by the client. Number of Bytes Represents the length of the chunk data. The chunk data should be 16 bit aligned. Rao, Lanphier Page 38 INTERNET-DRAFT RTSP November 26, 1996 6.5 APPENDIX E - Authors Contacts: At Netscape: Anup Rao At Progressive Networks: Rob Lanphier [Note: this list will need to be updated for the final release of the document] The following authors contributed to this document: Martin Dunsmuir General Manager Server Products, Progressive Networks 1111 Third Avenue, Suite 2900 Tel. 206 674 2700 (main #) John K. Ho Project Manager Netscape Communications Corp. 685 E. Middlefield Rd. Mountain View, CA, 94043 Tel. 415 254 1900 (main #) Rob Lanphier Program Manager Progressive Networks Eduardo F. Llach Manager, Media Server Team, Netscape Communications Corp. Rob McCool Technical Team Leader, Media Server Netscape Communications Corp. Igor Plotnikov Technical Team Leader, Media Server Netscape Communications Corp. Anup Rao Member, Technical Staff Netscape Communications Corp. Rao, Lanphier Page 39 INTERNET-DRAFT RTSP November 26, 1996 Pinaki Shah Member, Technical Staff Netscape Communications Corp. Alexander Sokolsky Member, Technical Staff Netscape Communications Corp. Dale Stammen Lead Saxophone Progressive Networks John Francis Stracke Senior LiveMedia Architect Netscape Communications Corp. Rao, Lanphier Page 40