Knowlegde Through Fun Welcome To Mady's Site.

Table summarizes the header fields used by RTSP. 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. Within this specification, DESCRIBE and GET_PARAMETER fall into this class.
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
Overview of RTSP header fields
Accept
The Accept request-header field can be used to specify certain presentation description content types which are acceptable for the response.
The "level" parameter for presentation descriptions is properly defined as part of the MIME type registration, not here.
Example of use:
Accept: application/rtsl, application/sdp;level=2
Accept-Language
Note that the language specified applies to the presentation description and any reason phrases, not the media content.



Allow
The Allow response header field lists the methods supported by the resource identified by the request-URI. The purpose of this field is to strictly inform the recipient of valid methods associated with the resource. An Allow header field must be present in a 405 (Method not allowed) response.
Example of use:
Allow: SETUP, PLAY, RECORD, SET_PARAMETER
Bandwidth
The Bandwidth request header field describes the estimated bandwidth available to the client, expressed as a positive integer and measured in bits per second. The bandwidth available to the client may change during an RTSP session, e.g., due to modem retraining.
Bandwidth = "Bandwidth" ":" 1*DIGIT
Example:
Bandwidth: 4000
Block size
This request header field is sent from the client to the media server asking the server for a particular media packet size. This packet size does not include lower-layer headers such as IP, UDP, or RTP. The server is free to use a block size which is lower than the one requested. The server MAY truncate this packet size to the closest multiple of the minimum, media-specific block size, or override it with the media-specific size if necessary. The block size MUST be a positive decimal number, measured in octets. The server only returns an error (416) if the value is syntactically invalid.
Cache-Control
The Cache-Control general header field is used to specify directives that MUST be obeyed by all caching mechanisms along the
request/response chain.
Cache directives must be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache- directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its response.
No-cache:
Indicates that the media stream MUST NOT is cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Public:
Indicates that the media stream is cacheable by any cache.
Private:
Indicates that the media stream is intended for a single user and MUST NOT be cached by a shared cache. A private (non- shared) cache may cache the media stream.
No-transform:
An intermediate cache (proxy) may find it useful to convert the media type of a certain stream. A proxy might, for example, convert between video formats to save cache space or to reduce the amount of traffic on a slow link. Serious operational problems may occur, however, when these transformations have been applied to streams intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication all depend on receiving a stream that is bit-for-bit identical to the original entity-body. Therefore, if a response includes the no-transform directive, an intermediate cache or proxy MUST NOT change the encoding of the stream. Unlike HTTP, RTSP does not provide for partial transformation at this point, e.g., allowing translation into a different language.
Only-if-cached:
In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those media streams that it currently has stored, and not to receive these from the origin server. To do this, the client may include the only-if-cached directive in a request. If it receives this directive, a cache SHOULD either respond using a cached media stream that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request MAY be forwarded within that group of caches.
Max-stale:
Indicates that the client is willing to accept a media stream that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
Min-fresh:
Indicates that the client is willing to accept a media stream whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
Must-revalidate:
When the must-revalidate directive is present in a SETUP response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. That is, the cache must do an end-to-end revalidation every time, if, based solely on the origin server's Expires, the cached response is stale.)
Conference
This request header field establishes a logical connection between a pre-established conference and an RTSP stream. The conference-id must not be changed for the same RTSP session.
Conference = "Conference" ":" conference-id Example:
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
A response code of 452 (452 Conference Not Found) is returned if the conference-id is not valid.
Content-Length
This field contains the length of the content of the method (i.e. after the double CRLF following the last header). Unlike HTTP, it MUST be included in all messages that carry content beyond the header portion of the message. If it is missing, a default value of zero is assumed.
Content-Type

Content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.

CSeq
The CSeq field specifies the sequence number for an RTSP request- response pair. This field MUST be present in all requests and responses. For every RTSP request containing the given sequence number, there will be a corresponding response having the same number. Any retransmitted request must contain the same sequence number as the original (i.e. the sequence number is not incremented for retransmissions of the same request).


Expires
The Expires entity-header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
DESCRIBE response:
The Expires header indicates a date and time after which the description should be considered stale.
A stale cache entry may not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
The format is an absolute date and time as defined by HTTP-date; it MUST be in RFC1123-date format:
Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
RTSP/1.0 clients and caches MUST treat other invalid date formats, especially including the value "0", as having occurred in the past (i.e., "already expired").
To mark a response as "already expired," an origin server should use an Expires date that is equal to the Date header value. To mark a response as "never expires," an origin server should use an Expires date approximately one year from the time the response is sent. RTSP/1.0 servers should not send Expires dates more than one year in the future.
The presence of an Expires header field with a date value of some time in the future on a media stream that otherwise would by default be non-cacheable indicates that the media stream is cacheable, unless indicated otherwise by a Cache-Control header field.
Host
This HTTP request header field is not needed for RTSP. It should be silently ignored if sent.


If-Match
This field is especially useful for ensuring the integrity of the presentation description, in both the case where it is fetched via means external to RTSP (such as HTTP), or in the case where the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message.
The identifier is an opaque identifier, and thus is not specific to any particular session description language.
If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE and SETUP methods to make them conditional. If the requested variant has not been modified since the time specified in this field, a description will not be returned from the server (DESCRIBE) or a stream will not be set up (SETUP). Instead, a 304 (not modified) response will be returned without any message-body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date

An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Last-Modified
The Last-Modified entity-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. For the methods DESCRIBE or ANNOUNCE, the header field indicates the last modification date and time of the description, for SETUP that of the media stream.
Proxy-Require
The Proxy-Require header is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client if not supported.
Range
This request and response header field specifies a range of time. The range can be specified in a number of units. This specification defines the smpte, npt, and clock range units. Within RTSP, byte ranges are not meaningful and MUST NOT be used. The header may also contain a time parameter in UTC, specifying the time at which the operation is to be made effective. Servers supporting the Range header MUST understand the NPT range format and SHOULD understand the SMPTE range format. The Range response header indicates what range of time is actually being played or recorded. If the Range header is given in a time format that is not understood, the recipient should return "501 Not Implemented".
Ranges are half-open intervals, including the lower point, but excluding the upper point. In other words, a range of a-b starts exactly at time a, but stops just before b. Only the start time of a media unit such as a video or audio frame is relevant. As an example, assume that video frames are generated every 40 ms. A range of 10.0- 10.1 would include a video frame starting at 10.0 or later time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08.
Range = "Range" ":" 1\#ranges-specifier
[“;" "time" "=" utc-time]
ranges-specifier = npt-range | utc-range | smpte-range
Example:
Range: clock=19960213T143205Z-; time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 byte- range header. It allows clients to select an excerpt from the media object, and to play from a given point to the end as well as from the current location to a given point. The start of playback can be scheduled for any time in the future, although a server may refuse to keep server resources for extended idle periods.
Require
The require header is used by clients to query the server about options that it may or may not support. The server MUST respond to this header by using the unsupported header to negatively acknowledge those options which are NOT supported.
This is to make sure that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the case above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes state ambiguity when the client requires features that the server does not understand.
RTP-Info
This field is used to set RTP-specific parameters in the PLAY response.
URL:
Indicates the stream URL which for which the following RTP parameters correspond.
Seq:
Indicates the sequence number of the first packet of the stream. This allows clients to gracefully deal with packets when seeking. The client uses this value to differentiate packets that originated before the seek from packets that originated after the seek.
rtptime:
Indicates the RTP timestamp corresponding to the time value in the Range response header. (Note: For aggregate control, a particular stream may not actually generate a packet for the Range time value returned or implied. Thus, there is no guarantee that the packet with the sequence number indicated by seq actually has the timestamp indicated by rtptime.) The client uses this value to calculate the mapping of RTP time to NPT.
A mapping from RTP timestamps to NTP timestamps (wall clock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP timestamps to NPT. Furthermore, in order to ensure that this information is available at the necessary time (immediately at startup or after a seek), and that it is delivered reliably, this mapping is placed in the RTSP control channel.
In order to compensate for drift for long, uninterrupted presentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping.
Syntax:
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
Stream-url = "url" "=" URL
parameter = ";" "seq" "=" 1*DIGIT
| ";" "rtptime" "=" 1*DIGIT
Example:
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102, url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
Scale
A scale value of 1 indicates normal play or record at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a ratio of 2 indicates twice the normal viewing rate ("fast forward") and a ratio of 0.5 indicates half the normal viewing rate. In other words, a ratio of 2 has normal play time increase at twice the wall clock rate. For every second of elapsed (wall clock) time, 2 seconds of content will be delivered. A negative value indicates reverse direction.
Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio.
The server should try to approximate the viewing rate, but may restrict the range of scale values that it supports. The response MUST contain the actual scale value chosen by the server.
If the request contains a Range parameter, the new scale value will take effect at that time.
Scale = "Scale" ":" [“-”] 1*DIGIT [“." *DIGIT]
Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5
Speed
This request header field’s parameter requests the server to deliver data to the client at a particular speed, contingent on the server's ability and desire to serve the media stream at the given speed. Implementation by the server is OPTIONAL. The default is the bit rate of the stream.
The parameter value is expressed as a decimal ratio, e.g., a value of 2.0 indicates that data is to be delivered twice as fast as normal. A speed of zero is invalid. If the request contains a Range parameter, the new speed value will take effect at that time.
Speed = "Speed" ":" 1*DIGIT [“." *DIGIT]
Example:
Speed: 2.5
Use of this field changes the bandwidth used for data delivery. It is meant for use in specific circumstances where preview of the presentation at a higher or lower rate is necessary. Implementers should keep in mind that bandwidth for the session may be negotiated beforehand (by means other than RTSP), and therefore re-negotiation may be necessary. When data is delivered over UDP, it is highly recommended that means such as RTCP be used to track packet loss rates.

Session
This request and response header field identifies an RTSP session started by the media server in a SETUP response and concluded by TEARDOWN on the presentation URL. The session identifier is chosen by the media server. Once a client receives a Session identifier, it MUST return it for any request related to that session. A server does not have to set up a session identifier if it has other means of identifying a session, such as dynamically generated URLs.
Session = "Session" ":" session-id [“;" "timeout" "=" delta-seconds]
The timeout parameter is only allowed in a response header. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands before closing the session due to lack of activity . The timeout is measured in seconds, with a default of 60 seconds (1 minute).
Note that a session identifier identifies a RTSP session across transport sessions or connections. Control messages for more than one RTSP URL may be sent within a single RTSP session. Hence, it is possible that clients use the same session for controlling many streams constituting a presentation, as long as all the streams come from the same server. However, multiple "user" sessions for the same URL from the same client MUST use different session identifiers.
The session identifier is needed to distinguish several delivery requests for the same URL coming from the same client.
The response 454 (Session Not found) is returned if the session identifier is invalid.
Timestamp
The timestamp general header describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and may use any timescale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that has elapsed since it has received the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the timeout value for retransmissions.
Timestamp = "Timestamp" ":" *(DIGIT) [“." *(DIGIT)] [delay]
Delay = *(DIGIT) [“." *(DIGIT)]
Transport
This request header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, and multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description. Transports are comma separated, listed in order of preference. Parameters may be added to each transport, separated by a semicolon.
The Transport header MAY also be used to change certain transport parameters. A server MAY refuse to change parameters of an existing stream.
The server MAY return a Transport response header in the response to indicate the values actually chosen. A Transport request header field may contain a list of transport options acceptable to the client. In that case, the server MUST return a single option which was actually chosen.
The syntax for the transport specifier is
Transport/profile/lower-transport.
The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP.
Below are the configuration parameters associated with transport:
General parameters:
unicast | multicast:
mutually exclusive indication of whether unicast or multicast delivery will be attempted. Default value is multicast. Clients that are capable of handling both unicast and multicast transmission MUST indicate such capability by including two full transport-specs with separate parameters for each.
Destination:
The address to which a stream will be sent. The client may specify the multicast address with the destination parameter. To avoid becoming the unwitting perpetrator of a remote- controlled denial-of-service attack, a server SHOULD authenticate the client and SHOULD log such attempts before allowing the client to direct a media stream to an address not chosen by the server. This is particularly important if RTSP commands are issued via UDP, but implementations cannot rely on TCP as reliable means of client identification by itself. A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from.
Source:
If the source address for the stream is different than can be derived from the RTSP endpoint address (the server in playback or the client in recording), the source MAY be specified.
This information may also be available through SDP. However, since this is more a feature of transport than media initialization, the authoritative source for this information should be in the SETUP response.
Layers:
The number of multicast layers to be used for this media stream. The layers are sent to consecutive addresses starting at the destination address.
Mode:
The mode parameter indicates the methods to be supported for this session. Valid values are PLAY and RECORD. If not provided, the default is PLAY.
Append:
If the mode parameter includes RECORD, the append parameter indicates that the media data should append to the existing resource rather than overwrite it. If appending is requested and the server does not support this, it MUST refuse the request rather than overwrite the resource identified by the URI. The append parameter is ignored if the mode parameter does not contain RECORD.
Interleaved:
The interleaved parameter implies mixing the media stream with the control stream in whatever protocol is being used by the control stream. The argument provides the channel number to be used in the $ statement. This parameter may be specified as a range, e.g., interleaved=4-5 in cases where the transport choice for the media stream requires it.
This allows RTP/RTCP to be handled similarly to the way that it is done with UDP, i.e., one channel for RTP and the other for RTCP.
Multicast specific:
ttl:
multicast time-to-live
RTP Specific:
Port:
This parameter provides the RTP/RTCP port pair for a multicast session. It is specified as a range, e.g., port=3456-3457.
client_port:
This parameter provides the unicast RTP/RTCP port pair on which the client has chosen to receive media data and control information. It is specified as a range, e.g.,
client_port=3456-3457.
server_port:
This parameter provides the unicast RTP/RTCP port pair on which the server has chosen to receive media data and control information. It is specified as a range, e.g.,
server_port=3456-3457.
Ssrc:
The ssrc parameter indicates the RTP SSRC value that should be (request) or will be (response) used by the media server. This parameter is only valid for unicast transmission. It identifies the synchronization source to be associated with the media stream.
Example:
Transport: RTP/AVP; multicast; ttl=127; mode="PLAY",
RTP/AVP; unicast; client_port=3456-3457; mode="PLAY"
The Transport header is restricted to describing a single RTP stream. (RTSP can also control multiple streams as a single entity.) Making it part of RTSP rather than relying on a multitude of session description formats greatly simplifies designs of firewalls.
Unsupported

The Unsupported response header lists the features not supported by the server. In the case where the feature was specified via the Proxy-Require field, if there is a proxy on the path between the client and the server, the proxy MUST insert a message reply with an error message "551 Option Not Supported".