18.1. Accept

The Accept request-header field can be used to specify certain presentation description and parameter media types [RFC4288] which are acceptable for the response to DESCRIBE and GET_PARAMETER requests.

See Section 20.2.3 for the syntax.

  Accept: application/example ;q=1.0, application/sdp

Example of use:

18.2. Accept-Credentials

The Accept-Credentials header is a request header used to indicate to any trusted intermediary how to handle further secured connections to proxies or servers. See Section 19 for the usage of this header. It MUST NOT be included in server to client requests.

In a request the header MUST contain the method (User, Proxy, or Any) for approving credentials selected by the requester. The method MUST NOT be changed by any proxy, unless it is "Proxy" when a proxy MAY change it to "user" to take the role of user approving each further hop. If the method is "User" the header contains zero or more of credentials that the client accepts. The header may contain zero credentials in the first RTSP request to a RTSP server when using the "User" method. This as the client has not yet received any credentials to accept. Each credential MUST consist of one URI identifying the proxy or server, the hash algorithm identifier, and the hash over that agent's DER encoded certificate [RFC5280] in Base64 [RFC4648]. All RTSP clients and proxies MUST implement the SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the DER encoded certificate. The SHA-256 algorithm is identified by the token "sha-256".

The intention with allowing for other hash algorithms is to enable the future retirement of algorithms that are not implemented somewhere else than here. Thus the definition of future algorithms for this purpose is intended to be extremely limited. A feature tag can be used to ensure that support for the replacement algorithm exist.

  Accept-Credentials:User
    "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
    "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=

Example:

18.3. Accept-Encoding

The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (see Section 18.14),i.e. transformation codings of the message body, such as gzip compression, that are acceptable in the response.

A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:

1. If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of 0 means "not acceptable.")
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
4. The "identity" content-coding is always acceptable, i.e. no transformation at all, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.

If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.

If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.

18.4. Accept-Language

The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Note that the language specified applies to the presentation description and any reason phrases, but not the media content.

A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. The syntax and registry of RTSP 2.0 language tags is the same as that defined by [RFC5646].

Each language-range MAY be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag if it exactly equals the full tag, or if it exactly equals a prefix of the tag, i.e., the primary-tag in the ABNF, such that the character following primary-tag is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in the Accept-Language field.

Note: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.

In the process of selecting a language, each language-tag is assigned a qualification factor, i.e., if a language being supported by the client is actually supported by the server and what "preference" level the language achieves. The quality value (q-value) of the longest language-range in the field that matches the language-tag is assigned as the qualification factor for a particular language-tag. If no language-range in the field matches the tag, the language qualification factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned a qualification factor greater than 0 are acceptable.

18.5. Accept-Ranges

The Accept-Ranges general-header field allows indication of the format supported in the Range header. The client MUST include the header in SETUP requests to indicate which formats it support to receive in PLAY and PAUSE responses, and REDIRECT requests. The server MUST include the header in SETUP and 456 error responses to indicate the formats supported for the resource indicated by the request URI. The header MAY be included in GET_PARAMETER request and response pairs. The GET_PARAMETER request MUST contain a Session header to identify the session context the request is related to. The requester and responder will indicate their capabilities regarding Range formats respectively.

   Accept-Ranges: NPT, SMPTE

The syntax is defined in Section 20.2.3.

18.6. Allow

The Allow message-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. The Allow header MUST also be present in all OPTIONS responses where the content of the header will not include exactly the same methods as listed in the Public header.

The Allow MUST also be included in SETUP and DESCRIBE responses, if the methods allowed for the resource is different than the complete set of methods defined in this memo.

   Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE

Example of use:

18.7. Authorization

An RTSP client that wishes to authenticate itself with a server using authentication mechanism from HTTP [RFC2617] , usually, but not necessarily, after receiving a 401 response, does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

When a shared cache (see Section 16) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:

1. If the response includes the "max-age" cache-control directive, the cache MAY use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. (This is the defined behavior for max-age.) If the response includes "max-age=0", the proxy MUST always revalidate it before re-using it.
2. If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request.
3. If the response includes the "public" cache-control directive, it MAY be returned in reply to any subsequent request.

18.8. Bandwidth

The Bandwidth request-header field describes the estimated bandwidth available to the client, expressed as a positive integer and measured in kilobits per second. The bandwidth available to the client may change during an RTSP session, e.g., due to mobility, congestion, etc.

Clients may not be able to accurately determine the available bandwidth, for example due to that first hop is not a bottleneck. For example most local area networks (LAN) will not be a bottleneck if the server is not in the same LAN. Thus link speeds of WLAN or Ethernet networks are normally not a basis for estimating the available bandwidth. Cellular devices or other devices directly connected to a modem or connection enabling device may more accurately estimate the bottleneck bandwidth and what is reasonable share of it for RTSP controlled media. The client will also need to take into account other traffic sharing the bottleneck. For example by only assigning a certain fraction to RTSP and its media streams. It is RECOMMENDED that only clients that have accurate and explicit information about bandwidth bottlenecks uses this header.

This header is not a substitute for proper congestion control. It is only a method providing an initial estimate and coarsely determines if the selected content can be delivered at all.

  Bandwidth: 62360

Example:

18.9. Blocksize

The Blocksize 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 blocksize 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 (4xx) if the value is syntactically invalid.

18.10. 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 DESCRIBE, GET_PARAMETER, SET_PARAMETER and SETUP request and its response. Note: Cache-Control does not govern only the caching of responses as for HTTP, instead it also applies to the media stream identified by the SETUP request. The RTSP requests are generally not cacheable, for further information see Section 16. Below is the description of the cache directives that can be included in the Cache-Control header.

no-cache:

Indicates that the media stream MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. Note, there is no security function enforcing that the content can't be cached.

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 streams.

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 media stream. 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 is required to do an end-to-end revalidation every time, if, based solely on the origin server's Expires, the cached response is stale.

proxy-revalidate:

The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later return the response without needing to revalidate it (since it has already been authenticated once by that user), while still requiring proxies that service many users to revalidate each time (in order to make sure that each user has been authenticated). Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at all.

max-age:

When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.

However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new message body and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new message body with a 200 (OK) response.

18.11. Connection

The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.

RTSP 2.0 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.

Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.

RTSP 2.0 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, Connection: close in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' [sec_connections-usage] after the current request/response is complete.

The use of the connection option "close" in RTSP messages SHOULD be limited to error messages when the server is unable to recover and therefore see it necessary to close the connection. The reason is that the client has the choice of continuing using a connection indefinitely, as long as it sends valid messages.

18.12. Connection-Credentials

The Connection-Credentials response header is used to carry the chain of credentials of any next hop that need to be approved by the requester. It MUST only be used in server to client responses.

The Connection-Credentials header in an RTSP response MUST, if included, contain the credential information (in form of a list of certificates providing the chain of certification) of the next hop that an intermediary needs to securely connect to. The header MUST include the URI of the next hop (proxy or server) and a base64 [RFC4648] encoded binary structure containing a sequence of DER encoded X.509v3 certificates[RFC5280] .

The binary structure starts with the number of certificates (NR_CERTS) included as a 16 bit unsigned integer. This is followed by NR_CERTS number of 16 bit unsigned integers providing the size in octets of each DER encoded certificate. This is followed by NR_CERTS number of DER encoded X.509v3 certificates in a sequence (chain). The proxy or server's certificate must come first in the structure. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...

Where MIIDNTCC... is a BASE64 encoding of the following structure:

     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 certificates       | Size of certificate #1        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Size of certificate #2        | Size of certificate #3        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    : DER Encoding of Certificate #1                                :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    : DER Encoding of Certificate #2                                :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    : DER Encoding of Certificate #3                                :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example:

18.13. Content-Base

Content-Base: rtsp://media.example.com/movie/twister/
 

The Content-Base message-header field may be used to specify the base URI for resolving relative URIs within the message body.

18.14. Content-Encoding

The Content-Encoding header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the message body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.

The content-coding is a characteristic of the message body identified by the Request-URI. Typically, the message body is stored with this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy MAY modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control directive is present in the message.

If the content-coding of a message body is not "identity", then the response MUST include a Content-Encoding Message-body header that lists the non-identity content-coding(s) used.

If the content-coding of a message body in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).

If multiple encodings have been applied to a message body, the content codings MUST be listed in the order in which they were applied, first to last from left to right. Additional information about the encoding parameters MAY be provided by other header fields not defined by this specification.

18.15. Content-Language

The Content-Language header field describes the natural language(s) of the intended audience for the enclosed message body. Note that this might not be equivalent to all the languages used within the message body.

Language tags are mentioned in Section 18.4. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is

Content-Language: da

If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.

Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented simultaneously in the original Maori and English versions, would call for

Content-Language: mi, en

However, just because multiple languages are present within a message body does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".

Content-Language MAY be applied to any media type -- it is not limited to textual documents.

18.16. Content-Length

The Content-Length general-header field contains the length of the message body of the RTSP message (i.e. after the double CRLF following the last header). Unlike HTTP, it MUST be included in all messages that carry a message body beyond the header portion of the RTSP message. If it is missing, a default value of zero is assumed. Any Content-Length greater than or equal to zero is a valid value.

18.17. Content-Location

The Content-Location header field MAY be used to supply the resource location for the message body enclosed in the message when that body is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response message body; especially in the case where a resource has multiple variants associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

As example, if an RTSP client performs a DESCRIBE request on a given resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", then the server may use additional information, such as the User-Agent header, to determine the capabilities of the agent. The server will then return a media description tailored to that class of RTSP agents. To indicate which specific description the agent receives the resource identifier ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location, while the description is still a valid response for the generic resource identifier. Thus enabling both debugging and cache operation as discussed below.

The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular variant at the time of the request. Future requests MAY specify the Content-Location URI as the request URI if the desire is to identify the source of that particular variant. This is useful if the RTSP agent desires to verify if the resource variant is current through a conditional request.

A cache cannot assume that a message body with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content- Location can be used to differentiate between multiple variants retrieved from a single requested resource.

If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.

Note, that Content-Location can be used in some cases to derive the base-URI for relative URI present in session description formats. This needs to be taken into account when Content-Location is used. The easiest way to avoid needing to consider that issue is to include the Content-Base whenever the Content-Location is included.

Note also, when using Media Tags in conjunction with Content-Location it is important that the different versions have different MTags, even if provided under different Content-Location URIs. This as they have still been provided under the same request URI.

Note also, as in most cases the URI used in the DESCRIBE and the SETUP requests are different, the URI provided in a DESCRIBE Content-Location response can't directly be used in a SETUP request. Instead the extra step of resolving URIs combined with the media descriptions indication, like with SDP's a=control attribute.

18.18. Content-Type

The Content-Type header indicates the media type of the message body sent to the recipient. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.

18.19. CSeq

The CSeq general-header 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, the corresponding response will have 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). For each new RTSP request the CSeq value MUST be incremented by one. The initial sequence number MAY be any number, however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its request to a server and the server has another when sending request to the client. Each requester and responder is identified with its socket address (IP address and port number).

Proxies that aggregate several sessions on the same transport will have to ensure that the requests sent towards a particular server have a joint sequence number space, i.e., they will regularly need to renumber the CSeq header field in requests (from proxy to server) and responses (from server to proxy) to fulfill the rules for the header. The proxy MUST increase the CSeq by one for each request it transmits, without regard of different sessions.

Example:

CSeq: 239

18.20. Date

The Date header field represents the date and time at which the message was originated. The inclusion of the Date header in RTSP message follows these rules:

• An RTSP message, sent either by the client or the server, containing a body MUST include a Date header, if the sending host has a clock;
• Clients and servers are RECOMMENDED to include a Date header in all other RTSP messages, if the sending host has a clock;
• If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, this rule MUST be followed: Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).

A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient. An RTSP implementation without a clock MUST NOT cache responses without revalidating them on every use. An RTSP cache, especially a shared cache, SHOULD use a mechanism, such as NTP, to synchronize its clock with a reliable external standard.

The RTSP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the message body is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.

18.21. Expires

The Expires message-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 presentation description (body) SHOULD be considered stale.

SETUP response:

The Expires header indicate a date and time after which the media stream SHOULD be considered stale.

A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the message body). See Section 16 for further discussion of the expiration model.

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.

  Expires: Thu, 01 Dec 1994 16:00:00 GMT

The format is an absolute date and time as defined by RTSP-date. An example of its use is

RTSP/2.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/2.0 servers SHOULD NOT send Expires dates more than one year in the future.

18.22. From

The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by "mailbox" in [RFC1123].

This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.

The Internet e-mail address in this field MAY be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used.

The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.

18.23. If-Match

The If-Match request-header field is especially useful for ensuring the integrity of the presentation description, independent of how the presentation description was received. The presentation description can be fetched via means external to RTSP (such as HTTP) or via the DESCRIBE message. In the case of retrieving the presentation description via RTSP, the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message. By including the MTag given in or with the session description in an If-Match header part of the SETUP request, the client ensures that resources set up are matching the description. A SETUP request with the If-Match header for which the MTag validation check fails, MUST generate a response using 412 (Precondition Failed).

This validation check is also very useful if a session has been redirected from one server to another.

18.24. 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 MUST be returned without any message-body.

  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

An example of the field is:

18.25. If-None-Match

This request header can be used with one or several message body tags to make DESCRIBE requests conditional. A client that has one or more message bodies previously obtained from the resource, can verify that none of those entities is current by including a list of their associated message body tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. As a special case, the value "*" matches any current entity of the resource.

If any of the message body tags match the message body tag of the message body that would have been returned in the response to a similar DESCRIBE request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was DESCRIBE, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related header fields (particularly MTag) of one of the message bodies that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed).

See Section 16.1.3 for rules on how to determine if two message body tags match.

If none of the message body tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no message body tags match, then the server MUST NOT return a 304 (Not Modified) response.

If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See Section 16.1.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)

The result of a request having both an If-None-Match header field and an If-Match header field is unspecified and MUST be considered an illegal request.

18.26. Last-Modified

The Last-Modified message-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. For the method DESCRIBE, the header field indicates the last modification date and time of the description, for SETUP that of the media stream.

An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date.

An origin server SHOULD obtain the Last-Modified value of the message body as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the message body's modification time, especially if the message body changes near the time that the response is generated.

RTSP servers SHOULD send Last-Modified whenever feasible.

18.27. Location

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.

Note: The Content-Location header field [sec_Content-Location] differs from Location in that the Content-Location identifies the original location of the message body enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also, see Section 16.2 for cache requirements of some methods.

18.28. Media-Properties

This general header is used in SETUP response or PLAY_NOTIFY requests to indicate the media's properties that currently are applicable to the RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any point. However, the client SHOULD have received the update prior to any action related to the new media properties take effect. For aggregated sessions, the Media-Properties header will be returned in each SETUP response. The header received in the latest response is the one that applies on the whole session from this point until any future update. The header MAY be included without value in GET_PARAMETER requests to the server with a Session header included to query the current Media-Properties for the session. The responder MUST include the current session's media properties.

The media properties expressed by this header is the one applicable to all media in the RTSP session. For aggregated sessions, the header expressed the combined media-properties. As a result, aggregation of media MAY result in a change of the media properties, and thus the content of the Media-Properties header contained in subsequent SETUP responses.

The header contains a list of property values that are applicable to the currently setup media or aggregate of media as indicated by the RTSP URI in the request. No ordering is enforced within the header. Property values should be grouped into a single group that handles a particular orthogonal property. Values or groups that express multiple properties SHOULD NOT be used. The list of properties that can be expressed MAY be extended at any time. Unknown property values MUST be ignored.

This specification defines the following 4 groups and their property values:

Random Access:

Random-Access:

Indicates that random access is possible. May optionally include a floating point value in seconds indicating the longest duration between any two random access points in the media.

Begining-Only:

Seeking is limited to the beginning only.

No-Seeking:

No seeking is possible.

Content Modifications:

Immutable:

The content will not be changed during the life-time of the RTSP session.

Dynamic:

The content may be changed based on external methods or triggers

Time-Progressing

The media accessible progresses as wallclock time progresses.

Retention:

Unlimited:

Content will be retained for the duration of the life-time of the RTSP session.

Time-Limited:

Content will be retained at least until the specified wallclock time. The time must be provided in the absolute time format specified in Section 4.6.

Time-Duration

Each individual media unit is retained for at least the specified time duration. This definition allows for retaining data with a time based sliding window. The time duration is expressed as floating point number in seconds. 0.0 is a valid value as this indicates that no data is retained in a time-progressing session.

Supported Scale:

Scales:

A quoted comma separated list of one or more decimal values or ranges of scale values supported by the content in arbitrary order. A range has a start and stop value separated by a colon. A range indicates that the content supports fine grained selection of scale values. Fine grained allows for steps at least as small as one tenth of a scale value. A content is considered to support fine grained selection when the server in response to a given scale value can produce content with an actual scale that is less than 1 tenth of scale unit, i.e., 0.1, from the requested value. Negative values are supported. The value 0 has no meaning and MUST NOT be used.

Examples of this header for on-demand content and a live stream without recording are:

On-demand:
Media-Properties: Random-Access=2.5s, Unlimited, Immutable, 
     Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"

Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0

18.29. Media-Range

The Media-Range general header is used to give the range of the media at the time of sending the RTSP message. This header MUST be included in SETUP response, and PLAY and PAUSE response for media that are Time-Progressing, and PLAY and PAUSE response after any change for media that are Dynamic, and in PLAY_NOTIFY request that are sent due to Media-Property-Update. Media-Range header without any range specifications MAY be included in GET_PARAMETER requests to the server to request the current range. The server MUST in this case include the current range at the time of sending the response.

The header MUST include range specifications for all time formats supported for the media, as indicated in Accept-Ranges header [sec_Accept-Ranges] when setting up the media. The server MAY include more than one range specification of any given time format to indicate media that has non-continuous range.

For media that has the Time-Progressing property, the Media-Range values will only be valid for the particular point in time when it was issued. As wallclock progresses so will also the media range. However, it shall be assumed that media time progresses in direct relationship to wallclock time (with the exception of clock skew) so that a reasonably accurate estimation of the media range can be calculated.

18.30. MTag

The MTag response header MAY be included in DESCRIBE, GET_PARAMETER or SETUP responses. The message body tags (Section 4.8) returned in a DESCRIBE response, and the one in SETUP refers to the presentation, i.e. both the returned session description and the media stream. This allows for verification that one has the right session description to a media resource at the time of the SETUP request. However, it has the disadvantage that a change in any of the parts results in invalidation of all the parts.

If the MTag is provided both inside the message body, e.g. within the "a=mtag" attribute in SDP, and in the response message, then both tags MUST be identical. It is RECOMMENDED that the MTag is primarily given in the RTSP response message, to ensure that caches can use the MTag without requiring content inspection. However, for session descriptions that are distributed outside of RTSP, for example using HTTP, etc. it will be necessary to include the message body tag in the session description as specified in Appendix D.1.9.

SETUP and DESCRIBE requests can be made conditional upon the MTag using the headers If-Match (Section 18.23) and If-None-Match ( Section 18.25).

18.31. Notify-Reason

The Notify Reason header is solely used in the PLAY_NOTIFY method. It indicates the reason why the server has sent the asynchronous PLAY_NOTIFY request (see Section 13.5).

18.32. Pipelined-Requests

The Pipelined-Requests general header is used to indicate that a request is to be executed in the context created by a previous request(s). The primary usage of this header is to allow pipelining of SETUP requests so that any additional SETUP request after the first one does not need to wait for the session ID to be sent back to the requesting agent. The header contains a unique identifier that is scoped by the persistent connection used to send the requests.

Upon receiving a request with the Pipelined-Requests the responding agent MUST look up if there exists a binding between this Pipelined-Requests identifier for the current persistent connection and an RTSP session ID. If that exists then the received request is processed the same way as if it contained the Session header with the found session ID. If there does not exist a mapping and no Session header is included in the request, the responding agent MUST create a binding upon the successful completion of a session creating request, i.e. SETUP. A binding MUST NOT be created, if the request failed to create an RTSP session. In case the request contains both a Session header and the Pipelined-Requests header the Pipelined-Requests MUST be ignored.

Note: Based on the above definition at least the first request containing a new unique Pipelined-Requests will be required to be a SETUP request (unless the protocol is extended with new methods of creating a session). After that first one, additional SETUP requests or request of any type using the RTSP session context may include the Pipelined-Requests header.

When responding to any request that contained the Pipelined-Requests header the server MUST also include the Session header when a binding to a session context exist. An RTSP agent that knows the session ID SHOULD NOT use the Pipelined-Requests header in any request and only use the Session header. This as the Session identifier is persistent across transport contexts, like TCP connections, which the Pipelined-Requests identifier is not.

The RTSP agent sending the request with a Pipelined-Requests header has the responsibility for using a unique and previously unused identifier within the transport context. Currently only a TCP connection is defined as such transport context. A server MUST delete the Pipelined-Requests identifier and its binding to a session upon the termination of that session. Despite the previous mandate, RTSP agents are RECOMMENDED to not reuse identifiers to allow for better error handling and logging.

RTSP Proxies may need to translate Pipelined-Requests identifier values from incoming requests to outgoing to allow for aggregation of requests onto a persistent connection.

18.33. Proxy-Authenticate

The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.

The HTTP access authentication process is described in [RFC2617]. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream agents. However, an intermediate proxy might need to obtain its own credentials by requesting them from the downstream agent, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header field.

18.34. Proxy-Authorization

The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.

The HTTP access authentication process is described in [RFC2617]. Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

18.35. Proxy-Require

The Proxy-Require request-header field 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 using the Unsupported header. The proxy MUST use the 551 (Option Not Supported) status code in the response. Any feature-tag included in the Proxy-Require does not apply to the end-point (server or client). To ensure that a feature is supported by both proxies and servers the tag needs to be included in also a Require header.

See Section 18.41 for more details on the mechanics of this message and a usage example. See discussion in the proxies section [sec_proxies_ext] about when to consider that a feature requires proxy support.

   Proxy-Require: play.basic

Example of use:

18.36. Proxy-Supported

The Proxy-Supported header field enumerates all the extensions supported by the proxy using feature-tags. The header carries the intersection of extensions supported by the forwarding proxies. The Proxy-Supported header MAY be included in any request by a proxy. It MUST be added by any proxy if the Supported header is present in a request. When present in a request, the receiver MUST in the response copy the received Proxy-Supported header.

The Proxy-Supported header field contains a list of feature-tags applicable to proxies, as described in Section 4.7. The list is the intersection of all feature-tags understood by the proxies. To achieve an intersection, the proxy adding the Proxy-Supported header includes all proxy feature-tags it understands. Any proxy receiving a request with the header, MUST check the list and removes any feature-tag(s) it does not support. A Proxy-Supported header present in the response MUST NOT be touched by the proxies.

  C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
         Supported: foo, bar, blech
         User-Agent: PhonyClient/1.2

 P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
         Supported: foo, bar, blech
         Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
         Via: 2.0 pro.example.com

 P2->S:  OPTIONS rtsp://example.com/ RTSP/2.0
         Supported: foo, bar, blech
         Proxy-Supported: proxy-foo, proxy-blech
         Via: 2.0 pro.example.com, 2.0 prox2.example.com

  S->C:  RTSP/2.0 200 OK
         Supported: foo, bar, baz
         Proxy-Supported: proxy-foo, proxy-blech
         Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
         Via: 2.0 pro.example.com, 2.0 prox2.example.com

Example:

18.37. Public

The Public response header field lists the set of methods supported by the response sender. This header applies to the general capabilities of the sender and its only purpose is to indicate the sender's capabilities to the recipient. The methods listed may or may not be applicable to the Request-URI; the Allow header field [sec_Allow] MAY be used to indicate methods allowed for a particular URI.

   Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN

Example of use:

In the event that there are proxies between the sender and the recipient of a response, each intervening proxy MUST modify the Public header field to remove any methods that are not supported via that proxy. The resulting Public header field will contain an intersection of the sender's methods and the methods allowed through by the intervening proxies.

In general, proxies should allow all methods to transparently pass through from the sending RTSP agent to the receiving RTSP agent, but there may be cases where this is not desirable for a given proxy. Modification of the Public response header field by the intervening proxies ensures that the request sender gets an accurate response indicating the methods that can be used on the target agent via the proxy chain.

18.38. Range

The Range header specifies a time range in PLAY (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be included in GET_PARAMETER requests from the client to the server with only a Range format and no value to request the current media position, whether the session is in Play or Ready state in the included format. The server SHALL, if supporting the range format, respond with the current playing point or pause point as the start of the range. If an explicit stop point was used in the previous PLAY request, then that value shall be included as stop point. Note that if the server is currently under any type of media playback manipulation affecting the interpretation of Range, like Scale, that is also required to be included in any GET_PARAMETER response to provide complete information.

The range can be specified in a number of units. This specification defines smpte (Section 4.4), npt (Section 4.5), and clock (Section 4.6) range units. While byte ranges [H14.35.1] and other extended units MAY be used, their behavior is unspecified since they are not normally meaningful in RTSP. Servers supporting the Range header MUST understand the NPT range format and SHOULD understand the SMPTE range format. If the Range header is sent in a time format that is not understood, the recipient SHOULD return 456 (Header Field Not Valid for Resource) and include an Accept-Ranges header indicating the supported time formats for the given resource.

  Range: clock=19960213T143205Z-

Example:

The Range header contains a range of one single range format. A range is a half-open interval with a start and an end point, including the start point, but excluding the end point. A range may either be fully specified with explicit values for start point and end point, or have either start or end point be implicit. An implicit start point indicates the session's pause point, and if no pause point is set the start of the content. An implicit end point indicates the end of the content. The usage of both implicit start and end point is not allowed in the same range header, however, the exclusion of the range header has that meaning, i.e. from pause point (or start) until end of content.

• Regarding the half-open intervals; a range of A-B starts exactly at time A, but ends just before B. Only the start time of a media unit such as a video or audio frame is relevant. For 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.
• Please note the difference between NPT time scales' "now" and an implicit start value. Implicit value reference the current pause-point. While "now" is the currently ongoing time. In a time-progressing session with recording (retention for some or full time) the pause point may be 2 min into the session while now could be 1 hour into the session.

By default, range intervals increase, where the second point is larger than the first point.

    Range: npt=10-15

Example:

However, range intervals can also decrease if the Scale header (see Section 18.44) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired.

    Scale: -1
    Range: npt=15-10

Example:

Decreasing ranges are still half open intervals as described above. Thus, for range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback for formats that have such a notion, like NPT and SMPTE.

    Scale: -1
    Range: npt=15-0

Example:

In this range both 15 and 0 are closed.

A decreasing range interval without a corresponding negative Scale header is not valid.

18.39. Referrer

The Referrer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. The URI refers to that of the presentation description, typically retrieved via HTTP. The Referrer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referrer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

If the field value is a relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment.

Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referrer field is sent. For example, a streaming client could have a toggle switch for openly/anonymously, which would respectively enable/disable the sending of Referrer and From information.

Clients SHOULD NOT include a Referrer header field in a (non-secure) RTSP request if the referring page was transferred with a secure protocol.

18.40. Request-Status

This request header is used to indicate the end result for requests that takes time to complete, such a PLAY [sec_PLAY]. It is sent in PLAY_NOTIFY [sec_PLAY_NOTIFY] with the end-of-stream reason to report how the PLAY request concluded, either in success or in failure. The header carries a reference to the request it reports on using the CSeq number for the session indicated by the Session header in the request. It provides both a numerical status code (according to Section 8.1.1) and a human readable reason phrase.

Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"

18.41. Require

The Require request-header field is used by clients to ensure that the other end-point supports features that are required in respect to this request. It can also be used to query if the other end-point supports certain features, however, the use of the Supported (Section 18.49) is much more effective in this purpose. The server MUST respond to this header by using the Unsupported header to negatively acknowledge those feature-tags which are NOT supported. The response MUST use the error code 551 (Option Not Supported). This header does not apply to proxies, for the same functionality in respect to proxies see Proxy-Require header (Section 18.35) with the exception of media modifying proxies. Media modifying proxies, due to their nature of handling media in a way that is very similar to a server, do need to understand also the server features to correctly serve the client.

This is to make sure that the client-server interaction will proceed without delay when all features are understood by both sides, and only slow down if features are not understood (as in the example below). 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.

C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
        CSeq: 302
        Require: funky-feature
        Funky-Parameter: funkystuff

S->C:   RTSP/2.0 551 Option not supported
        CSeq: 302
        Unsupported: funky-feature

Example (Not complete):

In this example, "funky-feature" is the feature-tag which indicates to the client that the fictional Funky-Parameter field is required. The relationship between "funky-feature" and Funky-Parameter is not communicated via the RTSP exchange, since that relationship is an immutable property of "funky-feature" and thus should not be transmitted with every exchange.

Proxies and other intermediary devices MUST ignore this header. If a particular extension requires that intermediate devices support it, the extension should be tagged in the Proxy-Require field instead (see Section 18.35). See discussion in the proxies section [sec_proxies_ext] about when to consider that a feature requires proxy support.

18.42. Retry-After

The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing the redirected request. The value of this field can be either an RTSP-date or an integer number of seconds (in decimal) after the time of the response.

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Example:

In the latter example, the delay is 2 minutes.

18.43. RTP-Info

The RTP-Info general header field is used to set RTP-specific parameters in the PLAY and GET_PARAMETER responses or a PLAY_NOTIFY and GET_PARAMETER requests. For streams using RTP as transport protocol the RTP-Info header SHOULD be part of a 200 response to PLAY.

The exclusion of the RTP-Info in a PLAY response for RTP transported media will result in that a client needs to synchronize the media streams using RTCP. This may have negative impact as the RTCP can be lost, and does not need to be particularly timely in its arrival. Also functionality as informing the client from which packet a seek has occurred is affected.

The RTP-Info MAY be included in SETUP responses to provide synchronization information when changing transport parameters, see Section 13.3. The RTP-Info header and the Range header MAY be included in a GET_PARAMETER request from client to server without any values to request the current playback point and corresponding RTP synchronization information. When the RTP-Info header is included in a Request also the Range header MUST be included (Note, Range header only MAY be used). The server response SHALL include both the Range header and the RTP-Info header. If the session is in Play state, then the value of the Range header SHALL be filled in with the current playback point and with the corresponding RTP-Info values. If the server is another state, no values are included in the RTP-Info header. The header is included in PLAY_NOTIFY requests with the Notify-Reason of end-of-stream to provide RTP information about the end of the stream.

The header can carry the following parameters:

url:

Indicates the stream URI for which the following RTP parameters correspond, this URI MUST be the same as used in the SETUP request for this media stream. Any relative URI MUST use the Request-URI as base URI. This parameter MUST be present.

ssrc:

The Synchronization source (SSRC) that the RTP timestamp and sequence number provided applies to. This parameter MUST be present.

seq:

Indicates the sequence number of the first packet of the stream that is direct result of the request. 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. Note that a client may not receive the packet with the expressed sequence number, and instead packets with a higher sequence number, due to packet loss or reordering. This parameter is RECOMMENDED to be present.

rtptime:

MUST indicate the RTP timestamp value corresponding to the start time value in the Range response header, or if not explicitly given the implied start point. The client uses this value to calculate the mapping of RTP time to NPT or other media timescale. This parameter SHOULD be present to ensure inter-media synchronization is achieved. There exists no requirement that any received RTP packet will have the same RTP timestamp value as the one in the parameter used to establish synchronization.

A mapping from RTP timestamps to NTP timestamps (wallclock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP timestamps to media clock time (NPT, etc.). 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.

Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
         rtptime=12345678,url="rtsp://example.com/foo/video"
         ssrc=9A9DE123:seq=30211;rtptime=29567112

Lets assume that Audio uses a 16kHz RTP timestamp clock and Video
a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way.

NPT    3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio               PA A
Video                  V    PV

X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
    corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which
    corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32

Example:

18.44. Scale

A scale value of 1 indicates normal play 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 content time increase at twice the playback time. For every second of elapsed (wallclock) time, 2 seconds of content time will be delivered. A negative value indicates reverse direction. For certain media transports this may require certain considerations to work consistent, see Appendix C.1 for description on how RTP handles this.

The transmitted data rate SHOULD NOT be changed by selection of a different scale value. The resulting bit-rate should be reasonably close to the nominal bit-rate of the content for Scale = 1. The server has to actively manipulate the data when needed to meet the bitrate constraints. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio, or completely mute the audio.

The server and content may restrict the range of scale values that it supports. The supported values are indicated by the Media-Properties header [sec_Media-Properties]. The client SHOULD only indicate request values to be supported. However, as the values may change as the content progresses a requested value may no longer be valid when the request arrives. Thus, a non-supported value in a request does not generate an error, only forces the server to choose the closest value. The response MUST always contain the actual scale value chosen by the server.

If the server does not implement the possibility to scale, it will not return a Scale header. A server supporting Scale operations for PLAY MUST indicate this with the use of the "play.scale" feature-tag.

When indicating a negative scale for a reverse playback, the Range header MUST indicate a decreasing range as described in Section 18.38.

  Scale: -3.5
  Range: npt=15-10

Example of playing in reverse at 3.5 times normal rate:

18.45. Seek-Style

When a client sends a PLAY request with a Range header to perform a random access to the media, the client does not know if the server will pick the first media samples or the first random access point prior to the request range. Depending on use case, the client may have a strong preference. To express this preference and provide the client with information on how the server actually acted on that preference the Seek-Style header is defined.

Seek-Style is a general header that MAY be included in any PLAY request to indicate the client's preference for any media stream that has random access properties. The server MUST always include the header in any PLAY response for media with random access properties to indicate what policy was applied. A server that receives an unknown Seek-Style policy MUST ignore it and select the server default policy. A client receiving an unknown policy MUST ignore it and use the Range header and any media synchronization information as basis to determine what the server did.

This specification defines the following seek policies that may be requested (see also Section 4.9.1):

RAP:

Random Access Point (RAP) is the behavior of requesting the server to locate the closest previous random access point that exists in the media aggregate and deliver from that. By requesting a RAP, media quality will be the best possible as all media will be delivered from a point where full media state can be established in the media decoder.

CoRAP:

Conditional Random Access Point (CoRAP) is a variant of the above RAP behavior. This policy is primarily intended for cases where there is larger distance between the random access points in the media. CoRAP is conditioned on that there is a Random Access Point closer to the requested start point than to the current pause point. This policy assumes that the media state existing prior to the pause is usable if delivery is continued. If the client or server knows that this is not the fact the RAP policy should be used. In other words: in most cases when the client requests a start point prior to the current pause point, a valid decoding dependency chain from the media delivered prior to the pause and to the requested media unit will not exist. If the server searched to a random access point the server MUST return the CoRAP policy in the Seek-Style header and adjust the Range header to reflect the position of the picked RAP. In case the random access point is further away and the server selects to continue from the current pause point it MUST include the "Next" policy in the Seek-Style header and adjust the Range header start point to the current pause point.

First-Prior:

The first-prior policy will start delivery with the media unit that has a playout time first prior to the requested time. For discrete media that would only include media units that would still be rendered at the request time. For continuous media that is media that will be rendered during the requested start time of the range.

Next:

The next media units after the provided start time of the range. For continuous framed media that would mean the first next frame after the provided time. For discrete media the first unit that is to be rendered after the provided time. The main usage for this case is when the client knows it has all media up to a certain point and would like to continue delivery so that a complete non-interrupted media playback can be achieved. Example of such scenarios include switching from a broadcast/multicast delivery to a unicast based delivery. This policy MUST only be used on the client's explicit request.

Please note that these expressed preferences exist for optimizing the startup time or the media quality. The "Next" policy breaks the normal definition of the Range header to enable a client to request media with minimal overlap, although some may still occur for aggregated sessions. RAP and First-Prior both fulfill the requirement of providing media from the requested range and forward. However, unless RAP is used, the media quality for many media codecs using predictive methods can be severely degraded unless additional data is available as, for example, already buffered, or through other side channels.

18.46. Server

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.

Example:

Server: PhonyServer/1.0

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field [sec_Via]. If the response is generated by the proxy, the proxy application MUST return the Server response-header as previously returned by the server.

18.47. Session

The Session request-header and response-header field identifies an RTSP session. An RTSP session is created by the server as a result of a successful SETUP request and in the response the session identifier is given to the client. The RTSP session exists until destroyed by a TEARDOWN, REDIRECT or timed out by the server.

The session identifier is chosen by the server (see Section 4.3) and MUST be returned in the SETUP response. Once a client receives a session identifier, it MUST be included in any request related to that session. This means that the Session header MUST be included in a request, using the following methods: PLAY, PAUSE, and TEARDOWN, and MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and REDIRECT, and MUST NOT be included in DESCRIBE. The Session header MUST NOT be included in the following methods, if these requests are pipelined and if the session identifier is not yet known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and GET_PARAMETER.

In an RTSP response the session header MUST be included in methods, SETUP, PLAY, and PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if included in the request of the following methods it MUST also be included in the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER, and MUST NOT be included in DESCRIBE responses.

Note that a session identifier identifies an RTSP session across transport sessions or connections. RTSP requests for a given session can use different URIs (Presentation and media URIs). Note, that there are restrictions depending on the session which URIs that are acceptable for a given method. However, multiple "user" sessions for the same URI from the same client will require use of different session identifiers.

The session identifier is needed to distinguish several delivery requests for the same URI coming from the same client.

The response 454 (Session Not Found) MUST be returned if the session identifier is invalid.

The header MAY include the session timeout period. If not explicitly provided this value is set to 60 seconds. As this affects how often session keep-alives are needed values smaller than 30 seconds are not recommended. However, larger than default values can be useful in applications of RTSP that have inactive but established sessions for longer time periods.

60 seconds was chosen as session timeout value due to: Resulting in not too frequent keep-alive messages and having low sensitivity to variations in request response timing. If one reduces the timeout value to below 30 seconds the corresponding request response timeout becomes a significant part of the session timeout. 60 seconds also allows for reasonably rapid recovery of committed server resources in case of client failure.

18.48. Speed

The Speed request-header field requests the server to deliver specific amounts of nominal media time per unit of delivery time, contingent on the server's ability and desire to serve the media stream at the given speed. The client requests the delivery speed to be within a given range with a lower and upper bound. The server SHALL deliver at the highest possible speed within the range, but not faster than the upper-bound, for which the underlying network path can support the resulting transport data rates. As long as any speed value within the given range can be provided the server SHALL NOT modify the media quality. Only if the server is unable to deliver media at the speed value provided by the lower bound shall it reduce the media quality.

Implementation of the Speed functionality by the server is OPTIONAL. The server can indicate its support through a feature-tag, play.speed. The lack of a Speed header in the response is an indication of lack of support of this functionality.

The speed parameter values are expressed as a positive decimal value, e.g., a value of 2.0 indicates that data is to be delivered twice as fast as normal. A speed value of zero is invalid. The range is specified in the form "lower bound - upper bound". The lower bound value may be smaller or equal to the upper bound. All speeds may not be possible to support. Therefore the server MAY modify the requested values to the closest supported. The actual supported speed MUST be included in the response. Note, however, that the use cases may vary and that Speed value ranges such as 0.7 - 0.8, 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage.

  Speed: 1.0-2.5
 

Example:

18.49. Supported

The Supported header enumerates all the extensions supported by the client or server using feature tags. The header carries the extensions supported by the message sending client or server. The Supported header MAY be included in any request. When present in a request, the receiver MUST respond with its corresponding Supported header. Note that the Supported header is also included in 4xx and 5xx responses.

The Supported header contains a list of feature-tags, described in Section 4.7, that are understood by the client or server.

  C->S:  OPTIONS rtsp://example.com/ RTSP/2.0
         Supported: foo, bar, blech
         User-Agent: PhonyClient/1.2

  S->C:  RTSP/2.0 200 OK
         Supported: bar, blech, baz

Example:

18.50. Terminate-Reason

The Terminate-Reason request header allows the server when sending a REDIRECT or TEARDOWN request to provide a reason for the session termination and any additional information. This specification identifies three reasons for Redirections and may be extended in the future:

Server-Admin:

The server needs to be shutdown for some administrative reason.

Session-Timeout:

A client's session is kept alive for extended periods of time and the server has determined that it needs to reclaim the resources associated with this session.

Internal-Error

An internal error that is impossible to recover from has occurred forcing the server to terminate the session.

The Server may provide additional parameters containing information around the redirect. This specification defines the following ones.

time:

Provides a wallclock time when the server will stop provide any service.

user-msg:

An UTF-8 text string with a message from the server to the user. This message SHOULD be displayed to the user.

18.51. Timestamp

The Timestamp general-header describes when the agent sent the request. The value of the timestamp is of significance only to the agent and may use any timescale. The responding agent 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 can be used by the agent to compute the round-trip time to the responding agent so that it can adjust the timeout value for retransmissions when running over an unreliable protocol. It also resolves retransmission ambiguities for unreliable transport of RTSP.

Note that the present specification provides only for reliable transport of RTSP messages. The Timestamp general-header is specified in case the protocol is extended in the future to use unreliable transport.

18.52. Transport

The Transport request and response header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description.

A Transport request header MAY contain a list of transport options acceptable to the client, in the form of multiple transport specification entries. Transport specifications are comma separated, listed in decreasing order of preference. Parameters may be added to each transport specification, separated by a semicolon. The server MUST return a Transport response-header in the response to indicate the values actually chosen if any. If the transport specification is not supported, no transport header is returned and the request MUST be responded using the status code 461 (Unsupported Transport) [sec_error461]. In case more than one transport specification was present in the request, the server MUST return the single (transport-spec) which was actually chosen, if any. The number of transport-spec entries is expected to be limited as the client will get guidance on what configurations that are possible from the presentation description.

The Transport header MAY also be used in subsequent SETUP requests to change transport parameters. A server MAY refuse to change parameters of an existing stream.

A transport specification may only contain one of any given parameter within it. Parameters MAY be given in any order. Additionally, it may only contain either of the unicast or the multicast transport type parameter. All parameters need to be understood in a transport specification, if not, the transport specification MUST be ignored. An RTSP proxy of any type that uses or modifies the transport specification, e.g. access proxy or security proxy, MUST remove specifications with unknown parameters before forwarding the RTSP message. If that results in no remaining transport specification the proxy SHALL send a 461 (Unsupported Transport) [sec_error461] response without any Transport header.

The Transport header is restricted to describing a single media 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.

Value1/Value2/Value3...

RTP/profile/lower-transport.

The general syntax for the transport specifier is a list of slash separated tokens:

The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP.

There are two different methods for how to specify where the media should be delivered for unicast transport:

dest_addr:

The presence of this parameter and its values indicates the destination address or addresses (host address and port pairs for IP flows) necessary for the media transport.

No dest_addr:

The lack of the dest_addr parameter indicates that the server MUST send media to same address for which the RTSP messages originates.

The choice of method for indicating where the media is to be delivered depends on the use case. In some cases the only allowed method will be to use no explicit address indication and have the server deliver media to the source of the RTSP messages.

For Multicast there is several methods for specifying addresses but they are different in how they work compared with unicast:

dest_addr with client picked address:

The address and relevant parameters, like TTL (scope), for the actual multicast group to deliver the media to. There are security implications [sec_security] with this method that need to be addressed if using this method because a RTSP server can be used as a DoS attacker on an existing multicast group.

dest_addr using Session Description Information:

The information included in the transport header can all be coming from the session description, e.g. the SDP c= and m= line. This mitigates some of the security issues of the previous methods as it is the session provider that picks the multicast group and scope. The client MUST include the information if it is available in the session description.

No dest_addr:

The behavior when no explicit multicast group is present in a request is not defined.

An RTSP proxy will need to take care. If the media is not desired to be routed through the proxy, the proxy will need to introduce the destination indication.

Below are the configuration parameters associated with transport:

General parameters:

unicast / multicast:

This parameter is a mutually exclusive indication of whether unicast or multicast delivery will be attempted. One of the two values MUST be specified. Clients that are capable of handling both unicast and multicast transmission needs to indicate such capability by including two full transport-specs with separate parameters for each.

layers:

The number of multicast layers to be used for this media stream. The layers are sent to consecutive addresses starting at the dest_addr address. If the parameter is not included, it defaults to a single layer.

dest_addr:

A general destination address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port. Note, only a single destination parameter per transport spec is intended. The usage of multiple destinations to distribute a single media to multiple entities is unspecified.

The client originating the RTSP request MAY specify the destination address of the stream recipient with the host address part of the tuple. When the destination address is specified, the recipient may be a different party than the originator of the request. To avoid becoming the unwitting perpetrator of a remote-controlled denial-of-service attack, a server MUST perform security checks (see Section 21.2.1) and SHOULD log such attempts before allowing the client to direct a media stream to a recipient address not chosen by the server. Implementations cannot rely on TCP as reliable means of client identification. If the server does not allow the host address part of the tuple to be set, it MUST return 463 (Destination Prohibited).

The host address part of the tuple MAY be empty, for example ":58044", in cases when only destination port is desired to be specified. Responses to requests including the Transport header with a dest_addr parameter SHOULD include the full destination address that is actually used by the server. The server MUST NOT remove address information present already in the request when responding unless the protocol requires it.

src_addr:

A general source address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port.

This parameter MUST be specified by the server if it transmits media packets from another address than the one RTSP messages are sent to. This will allow the client to verify source address and give it a destination address for its RTCP feedback packets, if RTP is used. The address or addresses indicated in the src_addr parameter SHOULD be used both for sending and receiving of the media streams data packets. The main reasons are threefold: First, indicating the port and source address(s) lets the receiver know where from the packets is expected to originate. Secondly, traversal of NATs is greatly simplified when traffic is flowing symmetrically over a NAT binding. Thirdly, certain NAT traversal mechanisms, needs to know to which address and port to send so called "binding packets" from the receiver to the sender, thus creating an address binding in the NAT that the sender to receiver packet flow can use.

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.

mode:

The mode parameter indicates the methods to be supported for this session. Currently defined valid values are "PLAY". If not provided, the default is "PLAY". The "RECORD" value was defined in RFC 2326 and is in this specification unspecified but reserved. RECORD and other values may be specified in the future.

interleaved:

The interleaved parameter implies mixing the media stream with the control stream in whatever protocol is being used by the control stream, using the mechanism defined in Section 14. The argument provides the channel number to be used in the $ block (see Section 14) and MUST be present. This parameter MAY be specified as an interval, e.g., interleaved=4-5 in cases where the transport choice for the media stream requires it, e.g., for RTP with RTCP. The channel number given in the request is only a guidance from the client to the server on what channel number(s) to use. The server MAY set any valid channel number in the response. The declared channel(s) are bi-directional, so both end-parties MAY send data on the given channel. One example of such usage is the second channel used for RTCP, where both server and client send RTCP packets on the same channel.

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.

MIKEY:

This parameter is used in conjunction with transport specifications that can utilize MIKEY [RFC3830] for security context establishment. So far only the SRTP based RTP profiles SAVP and SAVPF can utilize MIKEY and this is defined in Appendix C.1.4.1. This parameter can be included both in request and response messages. The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before being included in the value part of the parameter.

Multicast-specific:

ttl:

multicast time-to-live for IPv4. When included in requests the value indicate the TTL value that the client requests the server to use. In a response, the value actually being used by the server is returned. A server will need to consider what values that are reasonable and also the authority of the user to set this value. Corresponding functions are not needed for IPv6 as the scoping is part of the IPv6 multicast address [RFC4291].

RTP-specific:

These parameters MAY only be used if the media transport protocol is RTP.

ssrc:

The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [RFC3550] value(s) that will be used by the media server for RTP packets within the stream. It is expressed as an eight digit hexadecimal value.

The ssrc parameter MUST NOT be specified in requests. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP in RFC 3550[RFC3550]. If the parameter is included in the Transport header of a SETUP request, the server SHOULD ignore it, and choose appropriate SSRCs for the stream. The server SHOULD set the ssrc parameter in the Transport header of the response.

RTCP-mux:

Use to negotiate the usage of RTP and RTCP multiplexing [RFC5761] on a single underlying transport stream / flow. The presence of this parameter in a SETUP request indicates the client's support and requires the server to use RTP and RTCP multiplexing. The client SHALL only include one transport stream in the Transport header specification. To provide the server with a choice between using RTP/RTCP multiplexing or not, two different transport header specifications must be included.

The parameters setup and connection defined below MAY only be used if the media transport protocol of the lower-level transport is connection-oriented (such as TCP). However, these parameters MUST NOT be used when interleaving data over the RTSP control connection.

setup:

Clients use the setup parameter on the Transport line in a SETUP request, to indicate the roles it wishes to play in a TCP connection. This parameter is adapted from [RFC4145]. We discuss the use of this parameter in RTP/AVP/TCP non-interleaved transport in Appendix C.2.2; the discussion below is limited to syntactic issues. Clients may specify the following values for the setup parameter:

["active:"]

The client will initiate an outgoing connection.

["passive":]

The client will accept an incoming connection.

["actpass":]

The client is willing to accept an incoming connection or to initiate an outgoing connection.

If a client does not specify a setup value, the "active" value is assumed.

In response to a client SETUP request where the setup parameter is set to "active", a server's 2xx reply MUST assign the setup parameter to "passive" on the Transport header line.

In response to a client SETUP request where the setup parameter is set to "passive", a server's 2xx reply MUST assign the setup parameter to "active" on the Transport header line.

In response to a client SETUP request where the setup parameter is set to "actpass", a server's 2xx reply MUST assign the setup parameter to "active" or "passive" on the Transport header line.

Note that the "holdconn" value for setup is not defined for RTSP use, and MUST NOT appear on a Transport line.

connection:

Clients use the setup parameter on the Transport line in a SETUP request, to indicate the SETUP request prefers the reuse of an existing connection between client and server (in which case the client sets the "connection" parameter to "existing"), or that the client requires the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). Typically, clients use the "new" value for the first SETUP request for a URL, and "existing" for subsequent SETUP requests for a URL.

If a client SETUP request assigns the "new" value to "connection", the server response MUST also assign the "new" value to "connection" on the Transport line.

If a client SETUP request assigns the "existing" value to "connection", the server response MUST assign a value of "existing" or "new" to "connection" on the Transport line, at its discretion.

The default value of "connection" is "existing", for all SETUP requests (initial and subsequent).

The combination of transport protocol, profile and lower transport needs to be defined. A number of combinations are defined in the Appendix C.

  C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
        CSeq: 302
        Transport: RTP/AVP;multicast;mode="PLAY",
            RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
            "192.0.2.5:3457";mode="PLAY"
        Accept-Ranges: NPT, SMPTE, UTC
        User-Agent: PhonyClient/1.2

  S->C: RTSP/2.0 200 OK
        CSeq: 302
        Date: Thu, 23 Jan 1997 15:35:06 GMT
        Session: 47112344
        Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
           "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
           "192.0.2.224:6257";mode="PLAY"
        Accept-Ranges: NPT
        Media-Properties: Random-Access=0.6, Dynamic, 
                          Time-Limited=20081128T165900

Below is a usage example, showing a client advertising the capability to handle multicast or unicast, preferring multicast. Since this is a unicast-only stream, the server responds with the proper transport parameters for unicast.

18.53. Unsupported

The Unsupported response-header lists the features not supported by the responding RTSP agent. In the case where the feature was specified via the Proxy-Require field (Section 18.35), if there is a proxy on the path between the client and the server, the proxy MUST send a response message with a status code of 551 (Option Not Supported). The request MUST NOT be forwarded.

See Section 18.41 for a usage example.

18.54. User-Agent

The User-Agent general-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.

Example:

User-Agent: PhonyClient/1.2

18.55. Via

The Via general-header field MUST be used by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. The field is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

Multiple Via field values represents each proxy that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.

Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by default, forward the names and ports of hosts within the private/protected region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the via-received of any host behind the firewall/NAT SHOULD be replaced by an appropriate pseudonym for that host.

For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical sent-protocol values into a single such entry. Applications MUST NOT combine entries which have different received-protocol values.

18.56. WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

The HTTP access authentication process is described in [RFC2617]. User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.

19. Security Framework

The RTSP security framework consists of two high level components: the pure authentication mechanisms based on HTTP authentication, and the message transport protection based on TLS, which is independent of RTSP. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security for HTTP is re-used to a large extent.

19.1. RTSP and HTTP Authentication

RTSP and HTTP share common authentication schemes, and thus follow the same usage guidelines as specified in [RFC2617] and also in [H15]. Servers SHOULD implement both basic and digest [RFC2617] authentication. Clients MUST implement both basic and digest authentication [RFC2617] so that a server that requires the client to authenticate can trust that the capability is present.

It should be stressed that using the HTTP authentication alone does not provide full control message security. Therefore, in environments requiring tighter security for the control messages, TLS SHOULD be used, see Section 19.2.

19.2. RTSP over TLS

RTSP agents MUST implement RTSP over TLS as defined in this section and the next Section 19.3. RTSP MUST follow the same guidelines with regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818]. RTSP over TLS is separated from unsecured RTSP both on URI level and port level. Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier MUST be used to signal RTSP over TLS. If no port is given in a URI with the "rtsps" scheme, port 322 MUST be used for TLS over TCP/IP.

When a client tries to setup an insecure channel to the server (using the "rtsp" URI), and the policy for the resource requires a secure channel, the server MUST redirect the client to the secure service by sending a 301 redirect response code together with the correct Location URI (using the "rtsps" scheme). A user or client MAY upgrade a non secured URI to a secured by changing the scheme from "rtsp" to "rtsps". A server implementing support for "rtsps" MUST allow this.

It should be noted that TLS allows for mutual authentication (when using both server and client certificates). Still, one of the more common ways TLS is used is to only provide server side authentication (often to avoid client certificates). TLS is then used in addition to HTTP authentication, providing transport security and server authentication, while HTTP Authentication is used to authenticate the client.

RTSP includes the possibility to keep a TCP session up between the client and server, throughout the RTSP session lifetime. It may be convenient to keep the TCP session, not only to save the extra setup time for TCP, but also the extra setup time for TLS (even if TLS uses the resume function, there will be almost two extra round trips). Still, when TLS is used, such behavior introduces extra active state in the server, not only for TCP and RTSP, but also for TLS. This may increase the vulnerability to DoS attacks.

In addition to these recommendations, Section 19.3 gives further recommendations of TLS usage with proxies.

19.3. Security and Proxies

The nature of a proxy is often to act as a "man-in-the-middle", while security is often about preventing the existence of a "man-in-the-middle". This section provides clients with the possibility to use proxies even when applying secure transports (TLS) between the RTSP agents. The TLS proxy mechanism allows for server and proxy identification using certificates. However, the client cannot be identified based on certificates. The client needs to select between using the procedure specified below or using a TLS connection directly (by-passing any proxies) to the server. The choice may be dependent on policies.

There are basically two categories of proxies, the transparent proxies (of which the client is not aware) and the non-transparent proxies (of which the client is aware), see Section 15 for an introduction to RTSP proxies. An infrastructure based on proxies requires that the trust model is such that both client and servers can trust the proxies to handle the RTSP messages correctly. To be able to trust a proxy, the client and server also needs to be aware of the proxy. Hence, transparent proxies cannot generally be seen as trusted and will not work well with security (unless they work only at transport layer). In the rest of this section any reference to proxy will be to a non-transparent proxy, which inspects or manipulates the RTSP messages.

HTTP Authentication is built on the assumption of proxies and can provide user-proxy authentication and proxy-proxy/server authentication in addition to the client-server authentication.

When TLS is applied and a proxy is used, the client will connect to the proxy's address when connecting to any RTSP server. This implies that for TLS, the client will authenticate the proxy server and not the end server. Note that when the client checks the server certificate in TLS, it MUST check the proxy's identity (URI or possibly other known identity) against the proxy's identity as presented in the proxy's Certificate message.

The problem is that for a proxy accepted by the client, the proxy needs to be provided information on which grounds it should accept the next-hop certificate. Both the proxy and the user may have rules for this, and the user should have the possibility to select the desired behavior. To handle this case, the Accept-Credentials header (See Section 18.2) is used, where the client can request the proxy/proxies to relay back the chain of certificates used to authenticate any intermediate proxies as well as the server. The assumption that the proxies are viewed as trusted, gives the user a possibility to enforce policies to each trusted proxy of whether it should accept the next agent in the chain. However, it should be noted that not all deployments will return the chain of certificates used to authenticate any intermediate proxies as well as the server. An operator of such a deployment may want to hide its topology from the client. It should be noted well that the client does not have any insight into the proxy's operation. Even if the proxy is trusted, it can still return an incomplete chain of certificates.

A proxy MUST use TLS for the next hop if the RTSP request includes a "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between client and proxy, or between proxy and proxy), even if the resource and the end server are not required to use it. The proxy MUST, when initiating the next hop TLS connection, use the incoming TLS connections cipher suite list, only modified by removing any cipher suites that the proxy does not support. In case a proxy fails to establish a TLS connection due to cipher suite mismatch between proxy and next hop proxy or server, this is indicated using error code 472 (Failure to establish secure connection).

19.3.1. Accept-Credentials

The Accept-Credentials header can be used by the client to distribute simple authorization policies to intermediate proxies. The client includes the Accept-Credentials header to dictate how the proxy treats the server/next proxy certificate. There are currently three methods defined:

Any,

which means that the proxy (or proxies) MUST accept whatever certificate presented. This is of course not a recommended option to use, but may be useful in certain circumstances (such as testing).

Proxy,

which means that the proxy (or proxies) MUST use its own policies to validate the certificate and decide whether to accept it or not. This is convenient in cases where the user has a strong trust relation with the proxy. Reasons why a strong trust relation may exist are; personal/company proxy, proxy has a out-of-band policy configuration mechanism.

User,

which means that the proxy (or proxies) MUST send credential information about the next hop to the client for authorization. The client can then decide whether the proxy should accept the certificate or not. See Section 19.3.2 for further details.

If the Accept-Credentials header is not included in the RTSP request from the client, then the "Proxy" method MUST be used as default. If another method than the "Proxy" is to be used, then the Accept-Credentials header MUST be included in all of the RTSP requests from the client. This is because it cannot be assumed that the proxy always keeps the TLS state or the user's previous preference between different RTSP messages (in particular if the time interval between the messages is long).

With the "Any" and "Proxy" methods the proxy will apply the policy as defined for each method. If the policy does not accept the credentials of the next hop, the proxy MUST respond with a message using status code 471 (Connection Credentials not accepted).

An RTSP request in the direction server to client MUST NOT include the Accept-Credentials header. As for the non-secured communication, the possibility for these requests depends on the presence of a client established connection. However, if the server to client request is in relation to a session established over a TLS secured channel, it MUST be sent in a TLS secured connection. That secured connection MUST also be the one used by the last client to server request. If no such transport connection exists at the time when the server desires to send the request, the server MUST discard the message.

Further policies MAY be defined and registered, but should be done so with caution.

19.3.2. User approved TLS procedure

For the "User" method, each proxy MUST perform the following procedure for each RTSP request:

• Setup the TLS session to the next hop if not already present (i.e. run the TLS handshake, but do not send the RTSP request).
• Extract the peer certificate chain for the TLS session.
• Check if a matching identity and hash of the peer certificate is present in the Accept-Credentials header. If present, send the message to the next hop, and conclude these procedures. If not, go to the next step.
• The proxy responds to the RTSP request with a 470 or 407 response code. The 407 response code MAY be used when the proxy requires both user and connection authorization from user or client. In this message the proxy MUST include a Connection-Credentials header, see Section 18.12 with the next hop's identity and certificate.

The client MUST upon receiving a 470 or 407 response with Connection-Credentials header take the decision on whether to accept the certificate or not (if it cannot do so, the user SHOULD be consulted). If the certificate is accepted, the client has to again send the RTSP request. In that request the client has to include the Accept-Credentials header including the hash over the DER encoded certificate for all trusted proxies in the chain.

C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
      CSeq: 2
      Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                 "192.0.2.5:4589"
      Accept-Ranges: NPT, SMPTE, UTC
      Accept-Credentials: User

P->C: RTSP/2.0 470 Connection Authorization Required
      CSeq: 2
      Connection-Credentials: "rtsps://test.example.org";
      MIIDNTCCAp...

C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
      CSeq: 3
      Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                 "192.0.2.5:4589"
      Accept-Credentials: User "rtsps://test.example.org";sha-256;
      dPYD7txpoGTbAqZZQJ+vaeOkyH4=
      Accept-Ranges: NPT, SMPTE, UTC

P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
      CSeq: 3
      Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                 "192.0.2.5:4589"
      Via: RTSP/2.0 proxy.example.org
      Accept-Credentials: User "rtsps://test.example.org";sha-256;
      dPYD7txpoGTbAqZZQJ+vaeOkyH4=
      Accept-Ranges: NPT, SMPTE, UTC
      

Example:

One implication of this process is that the connection for secured RTSP messages may take significantly more round-trip times for the first message. A complete extra message exchange between the proxy connecting to the next hop and the client results because of the process for approval for each hop. However, if each message contains the chain of proxies that the requester accepts, the remaining message exchange should not be delayed. The procedure of including the credentials in each request rather than building state in each proxy, avoids the need for revocation procedures.

20. Syntax

The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) as defined in RFC 5234 [RFC5234]. It uses the basic definitions present in RFC 5234.

Please note that ABNF strings, e.g. "Accept", are case insensitive as specified in section 2.3 of RFC 5234.

The RTSP syntax makes use of the ISO 10646 character set in UTF-8 encoding RFC 3629 [RFC3629].

20.1. Base Syntax

RTSP header values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [RFC2616]. The SWS construct is used when linear white space is optional, generally between tokens and separators.

OCTET           =  %x00-FF ; any 8-bit sequence of data
CHAR            =  %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA         =  %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA         =  %x61-7A ;any US-ASCII lowercase letter "a".."z"
ALPHA           =  UPALPHA / LOALPHA
DIGIT           =  %x30-39 ; any US-ASCII digit "0".."9"
CTL             =  %x00-1F / %x7F  ; any US-ASCII control character
                   ; (octets 0 - 31) and DEL (127)
CR              =  %x0D ; US-ASCII CR, carriage return (13)
LF              =  %x0A  ; US-ASCII LF, linefeed (10)
SP              =  %x20  ; US-ASCII SP, space (32)
HT              =  %x09  ; US-ASCII HT, horizontal-tab (9)
BACKSLASH       =  %x5C  ; US-ASCII backslash (92)
CRLF            =  CR LF

LWS             =  [CRLF] 1*( SP / HT ) ; Line-breaking White Space
SWS             =  [LWS] ; Separating White Space
HCOLON          =  *( SP / HT ) ":" SWS
TEXT            =  %x20-7E / %x80-FF  ; any OCTET except CTLs
tspecials       =  "(" / ")" / "<" / ">" / "@"
                /  "," / ";" / ":" / BACKSLASH / DQUOTE
                /  "/" / "[" / "]" / "?" / "="
                /  "{" / "}" / SP / HT
token           =  1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                /  %x41-5A / %x5E-7A / %x7C / %x7E)
                   ; 1*<any CHAR except CTLs or tspecials>
quoted-string   =  ( DQUOTE *qdtext DQUOTE )
qdtext          = %x20-21 / %x23-5B / %x5D-7E / quoted-pair 
                / UTF8-NONASCII
                ; No DQUOTE and no "\"
quoted-pair     = "\\" / ( "\" DQUOTE )
ctext           =  %x20-27 / %x2A-7E
                /  %x80-FF  ; any OCTET except CTLs, "(" and ")"
generic-param   =  token [ EQUAL gen-value ]
gen-value       =  token / host / quoted-string

safe            =  "$" / "-" / "_" / "." / "+"
extra           =  "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra      =  "!" / "*" / "'" / "(" / ")" 

HEX             =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 
                /  "a" / "b" / "c" / "d" / "e" / "f"
LHEX            =  DIGIT /  "a" / "b" / "c" / "d" / "e" / "f" 
                   ; lowercase "a-f" Hex
reserved        =  ";" / "/" / "?" / ":" / "@" / "&" / "="

unreserved      =  ALPHA / DIGIT / safe / extra
rtsp-unreserved  =  ALPHA / DIGIT / safe / rtsp-extra

base64          =  *base64-unit [base64-pad]
base64-unit     =  4base64-char
base64-pad      =  (2base64-char "==") / (3base64-char "=")
base64-char     =  ALPHA / DIGIT / "+" / "/"

SLASH    =  SWS "/" SWS ; slash
EQUAL    =  SWS "=" SWS ; equal
LPAREN   =  SWS "(" SWS ; left parenthesis
RPAREN   =  SWS ")" SWS ; right parenthesis
COMMA    =  SWS "," SWS ; comma
SEMI     =  SWS ";" SWS ; semicolon
COLON    =  SWS ":" SWS ; colon
MINUS    =  SWS "-" SWS ; minus/dash
LDQUOT   =  SWS DQUOTE ; open double quotation mark
RDQUOT   =  DQUOTE SWS ; close double quotation mark
RAQUOT   =  ">" SWS ; right angle quote
LAQUOT   =  SWS "<" ; left angle quote

TEXT-UTF8char    =  %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-CONT        =  %x80-BF

POS-FLOAT        = 1*12DIGIT ["." 1*9DIGIT]
FLOAT            = ["-"] POS-FLOAT

To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a line break. The HCOLON defines this construct.

20.2. RTSP Protocol Definition

20.2.1. Generic Protocol elements

RTSP-IRI       =  schemes ":" IRI-rest
IRI-rest       =  ihier-part [ "?" iquery ]
ihier-part     =  "//" iauthority ipath-abempty
RTSP-IRI-ref   =  RTSP-IRI / irelative-ref
irelative-ref  =  irelative-part [ "?" iquery ] 
irelative-part =  "//" iauthority ipath-abempty
                  / ipath-absolute
                  / ipath-noscheme
                  / ipath-empty

iauthority     =  < As defined in RFC 3987>
ipath          =  ipath-abempty   ; begins with "/" or is empty
                  / ipath-absolute  ; begins with "/" but not "//"
                  / ipath-noscheme  ; begins with a non-colon segment
                  / ipath-rootless  ; begins with a segment
                  / ipath-empty     ; zero characters

ipath-abempty   =  *( "/" isegment )
ipath-absolute  =  "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme  =  isegment-nz-nc *( "/" isegment )
ipath-rootless  =  isegment-nz *( "/" isegment )
ipath-empty     =  0<ipchar>

isegment        =  *ipchar [";" *ipchar]
isegment-nz     =  1*ipchar [";" *ipchar]
                   / ";" *ipchar
isegment-nz-nc  =  (1*ipchar-nc [";" *ipchar-nc])
                   / ";" *ipchar-nc
                   ; non-zero-length segment without any colon ":"

ipchar         =  iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc      =  iunreserved / pct-encoded / sub-delims / "@"

iquery         =  < As defined in RFC 3987>
iunreserved    =  < As defined in RFC 3987>
pct-encoded    =  < As defined in RFC 3987>

RTSP-URI       =  schemes ":" URI-rest
RTSP-REQ-URI   =  schemes ":" URI-req-rest
RTSP-URI-Ref   =  RTSP-URI / RTSP-Relative
RTSP-REQ-Ref   =  RTSP-REQ-URI / RTSP-REQ-Rel
schemes        =  "rtsp" / "rtsps" / scheme
scheme         =  < As defined in RFC 3986>
URI-rest       =  hier-part [ "?" query ] 
URI-req-rest   =  hier-part [ "?" query ]
                  ; Note fragment part not allowed in requests
hier-part      =  "//" authority path-abempty

RTSP-Relative  =  relative-part [ "?" query ]
RTSP-REQ-Rel   =  relative-part [ "?" query ]
relative-part  =  "//" authority path-abempty
                  / path-absolute
                  / path-noscheme
                  / path-empty

authority      =  < As defined in RFC 3986>
query          =  < As defined in RFC 3986>

path           =  path-abempty    ; begins with "/" or is empty
                  / path-absolute ; begins with "/" but not "//"
                  / path-noscheme ; begins with a non-colon segment
                  / path-rootless ; begins with a segment
                  / path-empty    ; zero characters

path-abempty   =  *( "/" segment )
path-absolute  =  "/" [ segment-nz *( "/" segment ) ]
path-noscheme  =  segment-nz-nc *( "/" segment )
path-rootless  =  segment-nz *( "/" segment )
path-empty     =  0<pchar>

segment        =  *pchar [";" *pchar]
segment-nz     =  ( 1*pchar [";" *pchar]) / (";" *pchar)
segment-nz-nc  =  ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
                  ; non-zero-length segment without any colon ":"

pchar          =  unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc       =  unreserved / pct-encoded / sub-delims / "@"

sub-delims     =  "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / "="

smpte-range        =  smpte-type ["=" smpte-range-spec]
                      ; See section 3.4
smpte-range-spec   =  ( smpte-time "-" [ smpte-time ] )
                   /  ( "-" smpte-time )
smpte-type         =  "smpte" / "smpte-30-drop" 
                   /  "smpte-25" / smpte-type-extension
                   ; other timecodes may be added
smpte-type-extension  =  "smpte" token
smpte-time         =  1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 
                      [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]

npt-range        =  "npt" ["=" npt-range-spec]
npt-range-spec   =  ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time         =  "now" / npt-sec / npt-hhmmss
npt-sec          =  1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss       =  npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh           =  1*19DIGIT   ; any positive number
npt-mm           =  1*2DIGIT  ; 0-59
npt-ss           =  1*2DIGIT  ; 0-59

utc-range        =  "clock" ["=" utc-range-spec]
utc-range-spec   =  ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time         =  utc-date "T" utc-clock "Z" 
utc-date         =  8DIGIT                 
utc-clock        =  6DIGIT [ "." 1*9DIGIT ]

feature-tag       =  token

session-id        =  1*256( ALPHA / DIGIT / safe )

extension-header  =  header-name HCOLON header-value
header-name       =  token
header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)

20.2.2. Message Syntax

RTSP-message  = Request / Response  ; RTSP/2.0 messages

Request       = Request-Line  
                *((general-header 
                /  request-header  
                /  message-header) CRLF)   
                CRLF
                [ message-body-data ]      

Response     = Status-Line  
               *((general-header     
               /  response-header   
               /  message-header) CRLF)      
               CRLF
               [ message-body-data ]       

Request-Line = Method SP Request-URI SP RTSP-Version CRLF

Status-Line  = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

Method  =  "DESCRIBE" 
        /  "GET_PARAMETER"
        /  "OPTIONS" 
        /  "PAUSE"
        /  "PLAY"
        /  "PLAY_NOTIFY"
        /  "REDIRECT"
        /  "SETUP" 
        /  "SET_PARAMETER"
        /  "TEARDOWN" 
        /  extension-method

extension-method  =  token

Request-URI  =  "*" / RTSP-REQ-URI
RTSP-Version =  "RTSP/" 1*DIGIT "." 1*DIGIT

message-body-data = 1*OCTET

Status-Code  =  "100"  ; Continue
             /  "200"  ; OK
             /  "301"  ; Moved Permanently
             /  "302"  ; Found
             /  "303"  ; See Other
             /  "304"  ; Not Modified
             /  "305"  ; Use Proxy
             /  "400"  ; Bad Request
             /  "401"  ; Unauthorized
             /  "402"  ; Payment Required
             /  "403"  ; Forbidden
             /  "404"  ; Not Found
             /  "405"  ; Method Not Allowed
             /  "406"  ; Not Acceptable
             /  "407"  ; Proxy Authentication Required
             /  "408"  ; Request Time-out
             /  "410"  ; Gone
             /  "411"  ; Length Required
             /  "412"  ; Precondition Failed
             /  "413"  ; Request Message Body Too Large
             /  "414"  ; Request-URI Too Large
             /  "415"  ; Unsupported Media Type
             /  "451"  ; Parameter Not Understood
             /  "452"  ; reserved
             /  "453"  ; Not Enough Bandwidth
             /  "454"  ; Session Not Found
             /  "455"  ; Method Not Valid in This State
             /  "456"  ; Header Field Not Valid for Resource
             /  "457"  ; Invalid Range
             /  "458"  ; Parameter Is Read-Only
             /  "459"  ; Aggregate operation not allowed
             /  "460"  ; Only aggregate operation allowed
             /  "461"  ; Unsupported Transport
             /  "462"  ; Destination Unreachable
             /  "463"  ; Destination Prohibited
             /  "464"  ; Data Transport Not Ready Yet
             /  "465"  ; Notification Reason Unknown
             /  "466"  ; Key Management Error
             /  "470"  ; Connection Authorization Required
             /  "471"  ; Connection Credentials not accepted
             /  "472"  ; Failure to establish secure connection
             /  "500"  ; Internal Server Error
             /  "501"  ; Not Implemented
             /  "502"  ; Bad Gateway
             /  "503"  ; Service Unavailable
             /  "504"  ; Gateway Time-out
             /  "505"  ; RTSP Version not supported
             /  "551"  ; Option not supported
             /  extension-code
            
extension-code  =  3DIGIT

Reason-Phrase   =  1*(TEXT-UTF8char / HT / SP)

general-header  =  Cache-Control       
                /  Connection          
                /  CSeq                
                /  Date
                /  Media-Properties
                /  Media-Range
                /  Pipelined-Requests
                /  Proxy-Supported 
                /  Seek-Style 
                /  Server   
                /  Supported           
                /  Timestamp 
                /  User-Agent            
                /  Via                 
                /  extension-header

request-header  =  Accept               
                /  Accept-Credentials   
                /  Accept-Encoding      
                /  Accept-Language      
                /  Authorization        
                /  Bandwidth            
                /  Blocksize            
                /  From                 
                /  If-Match             
                /  If-Modified-Since    
                /  If-None-Match
                /  Notify-Reason
                /  Proxy-Require        
                /  Range                
                /  Referrer              
                /  Request-Status
                /  Require              
                /  Scale                
                /  Session              
                /  Speed                
                /  Supported            
                /  Terminate-Reason
                /  Transport                     
                /  extension-header

response-header  =  Accept-Credentials  
                 /  Accept-Ranges           
                 /  Connection-Credentials  
                 /  MTag                    
                 /  Location                
                 /  Proxy-Authenticate      
                 /  Public                  
                 /  Range                   
                 /  Retry-After             
                 /  RTP-Info                
                 /  Scale                   
                 /  Session                                   
                 /  Speed                   
                 /  Transport               
                 /  Unsupported             
                 /  WWW-Authenticate        
                 /  extension-header

message-header    =  Allow                
                 /  Content-Base         
                 /  Content-Encoding     
                 /  Content-Language     
                 /  Content-Length       
                 /  Content-Location     
                 /  Content-Type         
                 /  Expires              
                 /  Last-Modified        
                 /  extension-header

20.2.3. Header Syntax

Accept            =  "Accept" HCOLON
                     [ accept-range *(COMMA accept-range) ]
accept-range      =  media-type-range [SEMI accept-params]
media-type-range  =  ( "*/*"
                     / ( m-type SLASH "*" )
                     / ( m-type SLASH m-subtype )
                    ) *( SEMI m-parameter )
accept-params     =  "q" EQUAL qvalue *(SEMI generic-param )
qvalue            =  ( "0" [ "." *3DIGIT ] )
                  /  ( "1" [ "." *3("0") ] )
Accept-Credentials =  "Accept-Credentials" HCOLON cred-decision
cred-decision     =  ("User" [LWS cred-info]) 
                  /  "Proxy"
                  /  "Any"
                  /  (token [LWS 1*header-value])
				  ; For future extensions
cred-info         =  cred-info-data *(COMMA cred-info-data)

cred-info-data    =  DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg 
                     SEMI base64
hash-alg          =  "sha-256" / extension-alg
extension-alg     =  token
Accept-Encoding   =  "Accept-Encoding" HCOLON
                     [ encoding *(COMMA encoding) ]
encoding          =  codings [SEMI accept-params]
codings           =  content-coding / "*"
content-coding    =  token
Accept-Language   =  "Accept-Language" HCOLON
                     language *(COMMA language)
language          =  language-range [SEMI accept-params]
language-range    =  language-tag / "*" 
language-tag      =  primary-tag *( "-" subtag )
primary-tag       =  1*8ALPHA
subtag            =  1*8ALPHA
Accept-Ranges     =  "Accept-Ranges" HCOLON acceptable-ranges 
acceptable-ranges =  (range-unit *(COMMA range-unit)) 
range-unit        =  "NPT" / "SMPTE" / "UTC" / extension-format
extension-format  =  token
Allow             =  "Allow" HCOLON Method *(COMMA Method)
Authorization     =  "Authorization" HCOLON credentials
credentials       =  ("Digest" LWS digest-response)
                  /  other-response
digest-response   =  dig-resp *(COMMA dig-resp)
dig-resp          =  username / realm / nonce / digest-uri
                  /  dresponse / algorithm / cnonce
                  /  opaque / message-qop
                  /  nonce-count / auth-param
username          =  "username" EQUAL username-value
username-value    =  quoted-string
digest-uri        =  "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value  =  RTSP-REQ-URI
message-qop       =  "qop" EQUAL qop-value
cnonce            =  "cnonce" EQUAL cnonce-value
cnonce-value      =  nonce-value
nonce-count       =  "nc" EQUAL nc-value
nc-value          =  8LHEX
dresponse         =  "response" EQUAL request-digest
request-digest    =  LDQUOT 32LHEX RDQUOT
auth-param        =  auth-param-name EQUAL
                     ( token / quoted-string )
auth-param-name   =  token
other-response    =  auth-scheme LWS auth-param
                     *(COMMA auth-param)
auth-scheme       =  token

Bandwidth         =  "Bandwidth" HCOLON 1*19DIGIT 

Blocksize         =  "Blocksize" HCOLON 1*9DIGIT 

Cache-Control     =  "Cache-Control" HCOLON cache-directive 
                     *(COMMA cache-directive)
cache-directive   =  cache-rqst-directive
                  /  cache-rspns-directive

cache-rqst-directive =  "no-cache"
                     /  "max-stale" [EQUAL delta-seconds]
                     /  "min-fresh" EQUAL delta-seconds
                     /  "only-if-cached"
                     /  cache-extension

cache-rspns-directive =  "public"
                         /  "private"
                         /  "no-cache"
                         /  "no-transform"
                         /  "must-revalidate"
                         /  "proxy-revalidate"
                         /  "max-age" EQUAL delta-seconds
                         /  cache-extension

cache-extension   =  token [EQUAL (token / quoted-string)]
delta-seconds     =  1*19DIGIT

Connection         =  "Connection" HCOLON connection-token
                      *(COMMA connection-token) 
connection-token   =  "close" / token

Connection-Credentials = "Connection-Credentials" HCOLON cred-chain 
cred-chain         =  DQUOTE RTSP-REQ-URI DQUOTE SEMI base64

Content-Base       =  "Content-Base" HCOLON RTSP-URI 
Content-Encoding   =  "Content-Encoding" HCOLON
                      content-coding *(COMMA content-coding)
Content-Language   =  "Content-Language" HCOLON
                      language-tag *(COMMA language-tag)
Content-Length     =  "Content-Length" HCOLON 1*19DIGIT
Content-Location   =  "Content-Location" HCOLON RTSP-REQ-Ref
Content-Type       =  "Content-Type" HCOLON media-type
media-type         =  m-type SLASH m-subtype *(SEMI m-parameter)
m-type             =  discrete-type / composite-type
discrete-type      =  "text" / "image" / "audio" / "video"
                   /  "application" / extension-token
composite-type   =  "message" / "multipart" / extension-token
extension-token  =  ietf-token / x-token
ietf-token       =  token
x-token          =  "x-" token
m-subtype        =  extension-token / iana-token
iana-token       =  token
m-parameter      =  m-attribute EQUAL m-value
m-attribute      =  token
m-value          =  token / quoted-string

CSeq           =  "CSeq" HCOLON cseq-nr 
cseq-nr        =  1*9DIGIT
Date           =  "Date" HCOLON RTSP-date
RTSP-date      =  rfc1123-date ; HTTP-date
rfc1123-date   =  wkday "," SP date1 SP time SP "GMT"
date1          =  2DIGIT SP month SP 4DIGIT
                  ; day month year (e.g., 02 Jun 1982)
time           =  2DIGIT ":" 2DIGIT ":" 2DIGIT
                  ; 00:00:00 - 23:59:59
wkday          =  "Mon" / "Tue" / "Wed"
               /  "Thu" / "Fri" / "Sat" / "Sun"
month          =  "Jan" / "Feb" / "Mar" / "Apr"
               /  "May" / "Jun" / "Jul" / "Aug"
               /  "Sep" / "Oct" / "Nov" / "Dec"

Expires        =  "Expires" HCOLON RTSP-date
From           =  "From" HCOLON from-spec
from-spec      =  ( name-addr / addr-spec ) *( SEMI from-param )
name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec      =  RTSP-REQ-URI / absolute-URI
absolute-URI   =  < As defined in RFC 3986>
display-name   =  *(token LWS) / quoted-string
from-param     =  tag-param / generic-param
tag-param      =  "tag" EQUAL token
If-Match       =  "If-Match" HCOLON ("*" / message-tag-list)
message-tag-list =  message-tag *(COMMA message-tag)
message-tag      =  [ weak ] opaque-tag
weak             =  "W/"
opaque-tag       =  quoted-string
If-Modified-Since  =  "If-Modified-Since" HCOLON RTSP-date
If-None-Match    =  "If-None-Match" HCOLON ("*" / message-tag-list)
Last-Modified    =  "Last-Modified" HCOLON RTSP-date
Location         =  "Location" HCOLON RTSP-REQ-URI
Media-Properties = "Media-Properties" HCOLON [media-prop-list]
media-prop-list  = media-prop-value *(COMMA media-prop-value)
media-prop-value = ("Random-Access" [EQUAL POS-FLOAT])
                 / "Begining-Only"
                 / "No-Seeking"
                 / "Immutable"
                 / "Dynamic"
                 / "Time-Progressing"
                 / "Unlimited"
                 / ("Time-Limited" EQUAL utc-time)
                 / ("Time-Duration" EQUAL POS-FLOAT)
                 / ("Scales" EQUAL scale-value-list)
                 / media-prop-ext
media-prop-ext   = token [EQUAL (1*rtsp-unreserved / quoted-string)]
scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE
scale-entry      = scale-value / (scale-value COLON scale-value)
scale-value      = FLOAT
Media-Range      = "Media-Range" HCOLON [ranges-list]
ranges-list      =  ranges-spec *(COMMA ranges-spec)
MTag             =  "MTag" HCOLON message-tag
Notify-Reason    = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val  = "end-of-stream" 
                 / "media-properties-update"
                 / "scale-change"
                 / Notify-Reason-extension
Notify-Reason-extension  = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id  = 1*8DIGIT

Proxy-Authenticate   =  "Proxy-Authenticate" HCOLON challenge-list
challenge-list       =  challenge *(COMMA challenge)
challenge            =  ("Digest" LWS digest-cln *(COMMA digest-cln))
                     /  other-challenge
other-challenge      =  auth-scheme LWS auth-param
                        *(COMMA auth-param)
digest-cln           =  realm / domain / nonce
                     /  opaque / stale / algorithm
                     /  qop-options / auth-param
realm                =  "realm" EQUAL realm-value
realm-value          =  quoted-string
domain               =  "domain" EQUAL LDQUOT RTSP-REQ-Ref
                        *(1*SP RTSP-REQ-Ref ) RDQUOT
nonce                =  "nonce" EQUAL nonce-value
nonce-value          =  quoted-string
opaque               =  "opaque" EQUAL quoted-string
stale                =  "stale" EQUAL ( "true" / "false" )
algorithm            =  "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options          =  "qop" EQUAL LDQUOT qop-value
                        *("," qop-value) RDQUOT
qop-value            =  "auth" / "auth-int" / token
Proxy-Require        =  "Proxy-Require" HCOLON feature-tag-list
feature-tag-list     =  feature-tag *(COMMA feature-tag)  
Proxy-Supported      =  "Proxy-Supported" HCOLON [feature-tag-list]

Public               =  "Public" HCOLON Method *(COMMA Method) 

Range                =  "Range" HCOLON ranges-spec 

ranges-spec          =  npt-range / utc-range / smpte-range
                     /  range-ext
range-ext            =  extension-format ["=" range-value]
range-value          =  1*(rtsp-unreserved / quoted-string / ":" )

Referrer             =  "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) 
Request-Status       =  "Request-Status" HCOLON req-status-info
req-status-info      =  cseq-info LWS status-info LWS reason-info
cseq-info            =  "cseq" EQUAL cseq-nr
status-info          =  "status" EQUAL Status-Code
reason-info          =  "reason" EQUAL DQUOTE Reason-Phrase DQUOTE 
Require              =  "Require" HCOLON feature-tag-list 

RTP-Info         =  "RTP-Info" HCOLON [rtsp-info-spec
                    *(COMMA rtsp-info-spec)] 
rtsp-info-spec   =  stream-url 1*ssrc-parameter 
stream-url       =  "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE 
ssrc-parameter   =  LWS "ssrc" EQUAL ssrc HCOLON
                    ri-parameter *(SEMI ri-parameter)
ri-parameter     =  ("seq" EQUAL 1*5DIGIT)
                 /  ("rtptime" EQUAL 1*10DIGIT)
                 /  generic-param

Retry-After      =  "Retry-After" HCOLON ( RTSP-date / delta-seconds )
Scale            =  "Scale" HCOLON scale-value 
Seek-Style       =  "Seek-Style" HCOLON Seek-S-values
Seek-S-values    =  "RAP"
                 /  "CoRAP"
                 /  "First-Prior"
                 /  "Next"
                 /  Seek-S-value-ext
Seek-S-value-ext =  token

Server           =  "Server" HCOLON ( product / comment )
                    *(LWS (product / comment)) 
product          =  token [SLASH product-version]
product-version  =  token
comment          =  LPAREN *( ctext / quoted-pair) RPAREN

Session          =  "Session" HCOLON session-id 
                    [ SEMI "timeout" EQUAL delta-seconds ] 

Speed            =  "Speed" HCOLON lower-bound MINUS upper-bound
lower-bound      =  POS-FLOAT
upper-bound      =  POS-FLOAT

Supported        =  "Supported" HCOLON [feature-tag-list] 

Terminate-Reason      =  "Terminate-Reason" HCOLON TR-Info
TR-Info              =  TR-Reason *(SEMI TR-Parameter)
TR-Reason            =  "Session-Timeout" 
                     /  "Server-Admin"
                     /  "Internal-Error"
                     /  token
TR-Parameter         =  TR-time / TR-user-msg / generic-param
TR-time              =  "time" EQUAL utc-time
TR-user-msg          =  "user-msg" EQUAL quoted-string

Timestamp        =  "Timestamp" HCOLON timestamp-value [LWS delay]
timestamp-value  =  *19DIGIT [ "." *9DIGIT ]
delay            =  *9DIGIT [ "." *9DIGIT ]

Transport        =  "Transport" HCOLON transport-spec 
                    *(COMMA transport-spec) 
transport-spec   =  transport-id *trns-parameter
transport-id     =  trans-id-rtp / other-trans
trans-id-rtp     =  "RTP/" profile ["/" lower-transport]
                    ; no LWS is allowed inside transport-id 
other-trans      =  token *("/" token)

profile             = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport     = "TCP" / "UDP" / token
trns-parameter      = (SEMI ( "unicast" / "multicast" ))
                    / (SEMI "interleaved" EQUAL channel [ "-" channel ])
                    / (SEMI "ttl" EQUAL ttl)
                    / (SEMI "layers" EQUAL 1*DIGIT)
                    / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
                    / (SEMI "mode" EQUAL mode-spec)
                    / (SEMI "dest_addr" EQUAL addr-list)
                    / (SEMI "src_addr" EQUAL addr-list)
                    / (SEMI "setup" EQUAL contrans-setup)
                    / (SEMI "connection" EQUAL contrans-con)
                    / (SEMI "RTCP-mux")
                    / (SEMI "MIKEY" EQUAL MIKEY-Value)
                    / (SEMI trn-param-ext)
contrans-setup      = "active" / "passive" / "actpass"
contrans-con        = "new" / "existing"
trn-param-ext       = par-name [EQUAL trn-par-value]
par-name            = token
trn-par-value       = *(rtsp-unreserved / quoted-string)
ttl                 = 1*3DIGIT ; 0 to 255
ssrc                = 8HEX
channel             = 1*3DIGIT ; 0 to 255
MIKEY-Value         = base64
mode-spec           = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode                = "PLAY" / token
addr-list           = quoted-addr *(SLASH quoted-addr)
quoted-addr         = DQUOTE (host-port / extension-addr) DQUOTE
host-port           = ( host [":" port] )
                    / ( ":" port )
extension-addr      = 1*qdtext
host                = < As defined in RFC 3986>
port                = < As defined in RFC 3986>

Unsupported     = "Unsupported" HCOLON feature-tag-list 

User-Agent      = "User-Agent" HCOLON ( product / comment ) 
                  *(LWS (product / comment)) 

field-name-list = field-name *(COMMA field-name)
field-name      = token
Via             = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm        = sent-protocol LWS sent-by *( SEMI via-params )
via-params      = via-ttl / via-maddr
                / via-received / via-extension
via-ttl         = "ttl" EQUAL ttl
via-maddr       = "maddr" EQUAL host
via-received    = "received" EQUAL (IPv4address / IPv6address)
IPv4address     = < As defined in RFC 3986>
IPv6address     = < As defined in RFC 3986>
via-extension   = generic-param
sent-protocol   = protocol-name SLASH protocol-version
                  SLASH transport-prot
protocol-name   = "RTSP" / token
protocol-version = token
transport-prot  = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token
sent-by         = host [ COLON port ]

WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list

20.3. SDP extension Syntax

control-attribute   =  "a=control:" *SP RTSP-REQ-Ref CRLF

a-range-def         =  "a=range:" ranges-spec CRLF

a-mtag-def          =  "a=mtag:" message-tag CRLF

This section defines in ABNF the SDP extensions defined for RTSP. See Appendix D for the definition of the extensions in text.

21. Security Considerations

The security considerations and threats around RTSP and its usage can be divided into considerations around the signaling protocol itself and the issues related to the media stream delivery. However, when it comes to mitigations of security threats, a threat depending on the media stream delivery may in fact be mitigated by a mechanism in the signaling protocol.

There are several chapters and appendix in this document that define security solutions for the protocol. We will reference them when discussing the threats below. But the reader should take special notice of the Security Framework [sec_security-framework] and the specification of how to use SRTP and its key-mangement [sec-savp] to achieve certain aspects of the media security.

21.1. Signaling Protocol Threats

This section focuses on issues related to the signaling protocol. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in [H15] apply also.

Specifically, please note the following:

Abuse of Server Log Information:

RTSP and HTTP servers will presumably have similar logging mechanisms, and thus should be equally guarded in protecting the contents of those logs, thus protecting the privacy of the users of the servers. See [H15.1.1] for HTTP server recommendations regarding server logs.

Transfer of Sensitive Information:

There is no reason to believe that information transferred or controlled via RTSP may be any less sensitive than that normally transmitted via HTTP. Therefore, all of the precautions regarding the protection of data privacy and user privacy apply to implementors of RTSP clients, servers, and proxies. See [H15.1.2] for further details.

Attacks Based On File and Path Names:

Though RTSP URIs are opaque handles that do not necessarily have file system semantics, it is anticipated that many implementations will translate portions of the Request-URIs directly to file system calls. In such cases, file systems SHOULD follow the precautions outlined in [H15.5], such as checking for ".." in path components.

Personal Information:

RTSP clients are often privy to the same information that HTTP clients are (user name, location, etc.) and thus should be equally sensitive. See [H15.1] for further recommendations.

Privacy Issues Connected to Accept Headers:

Since may of the same "Accept" headers exist in RTSP as in HTTP, the same caveats outlined in [H15.1.4] with regards to their use should be followed.

DNS Spoofing:

Presumably, given the longer connection times typically associated to RTSP sessions relative to HTTP sessions, RTSP client DNS optimizations should be less prevalent. Nonetheless, the recommendations provided in [H15.3] are still relevant to any implementation which attempts to rely on a DNS-to-IP mapping to hold beyond a single use of the mapping.

Location Headers and Spoofing:

If a single server supports multiple organizations that do not trust each another, then it MUST check the values of Location and Content-Location header fields in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority. ([H15.4])

In addition to the recommendations in the current HTTP specification (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC 2068 [RFC2068], future HTTP specifications may provide additional guidance on security issues.

The following are added considerations for RTSP implementations. Security Framework [sec_security-framework] namely client authentication using HTTP authentication and TLS based transport protection of the signaling messages. Both of these mechanisms are required to be implemented by any RTSP agent.

Session hijacking:

Since there is no or little relation between a transport layer connection and an RTSP session, it is possible for a malicious client to issue requests with random session identifiers which could affect other clients of an unsuspecting server. To mitigate this the server SHALL use a large, random and non-sequential session identifier to minimize the possibility of this kind of attack. However, unless the RTSP signaling is always confidentiality protected, e.g. using TLS, an on-path attacker will be able to hijack a session. To prevent session hijacking client authentication needs to be performed and only the authenticated client creating the session SHALL be able to access that session.

Authentication:

Servers SHOULD implement both basic and digest [RFC2617] authentication. In environments requiring tighter security for the control messages, the transport layer mechanism TLS [RFC5246] SHOULD be used.

Persistently suspicious behavior:

RTSP servers SHOULD return error code 403 (Forbidden) upon receiving a single instance of behavior which is deemed a security risk. RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients which are deemed to be in violation of local security policy.

TLS through proxies:

If one uses the possibility to connect TLS in multiple legs (Section 19.3) one really needs to be aware of the trust model. That procedure requires full faith and trust in all proxies, which will be identified, that one allows to connect through. They are men in the middle and have access to all that goes on over the TLS connection. Thus it is important to consider if that trust model is acceptable in the actual application. Further discussion of the actual trust model is in Section 19.3.

Resource Exhaustion:

As RTSP is a stateful protocol and establishes resource usage on the server there is a clear possibility to attack the server by trying to overbook these resources to perform a denial of service attack. This attack can be both against ongoing sessions and to prevent others from establishing sessions. RTSP agents will need to have mechanisms to prevent single peers from consuming extensive amounts of resources. The methods for guarding against this are varied and depends on the agent's role and capabilities and policies. Each implementation has to carefully consider their methods and policies to mitigate this threat. For example regarding handling of connections there are recommendations in Section 10.7.

The above threats and considerations have resulted in a set of security functions and mechanisms built into or used by the protocol. The signaling protocol relies on two security features defined in the

A number of different security mitigations have been designed into the protocol and will be present by following the specification as written, for example by ensuring sufficient amount of entropy in the randomly generated session identifiers when not using client authentication to prevent session hijacking. When client authentication is used the protection against hijacking will be strongly improved by scoping the accessible sessions to the one this client identity has created. Some of the above threats are such that the implementation of the RTSP functionality itself needs to consider which policy and strategy it uses to mitigate them.

21.2. Media Stream Delivery Threats

The fact that RTSP establishes and controls a media stream delivery results in a set of security issues related to the media streams. This section will attempt to analyze general threats, however the choice of media stream transport protocol, like RTP will result in some differences in threats and what mechanisms that exist to mitigate them. Thus it becomes important that each specification of a new media stream transport and delivery protocol usable by RTSP requires its own security analysis. This section includes one for RTP.

The set of general threats from or by the media stream delivery itself are:

Concentrated denial-of-service attack:

The protocol offers the opportunity for a remote-controlled denial-of-service (DoS) attack, where the media stream is the hammer in that DoS attack. See Section 21.2.1.

Media Confidentiality:

The media delivery may contain content of any type and it is not possible in general to determine how sensitive this content is from a confidentiality point. Thus it is a strong requirement that any media delivery protocol provides a method for providing confidentiality of the actual media content. In addition to the media level confidentiality it becomes critical that no resource identifiers used in the signaling are exposed to an attacker as they may have human understandable names, or may be also available to the attacker so they can determine the content the user was delivered. Thus also the signaling protocol must provide confidentiality protection of any information related to the media resource.

Media Integrity and Authentication:

There are several reasons, such as discrediting the target, misinformation of the target, why an attacker will have interest to substitute the media stream sent out from the RTSP server with one of the attacker's creation or selection. Therefore it is important that the media protocol provides mechanisms to verify the source authentication, integrity and prevent replay attacks on the media stream.

Scope of Multicast:

If RTSP is used to control the transmission of media onto a multicast network it is needed to consider the scope that delivery has. RTSP supports the TTL Transport header parameter to indicate this scope for IPv4. IPv6 has a different mechanism for scope boundary. However, such scope control has risks, as it may be set too large and distribute media beyond the intended scope.

Below [sec-rtp-sec] we do a protocol specific analysis of security considerations for RTP based media transport. In that section we also make clear the requirements on implementing security functions for RTSP agents supporting media delivery over RTP.

21.2.1. Remote Denial of Service Attack

The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in prevention of more attacks or ascertaining the attackers identity. Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms. Security mechanisms that are acceptable in an increased generality are:

• Verification of the client's identity against a database of known users using RTSP authentication mechanisms (preferably digest authentication or stronger)
• A list of addresses that accept to be media destinations, especially considering user identity
• Media path based verification

The server SHOULD NOT allow the destination field to be set unless a mechanism exists in the system to authorize the request originator to direct streams to the recipient. It is preferred that this authorization be performed by the media recipient (destination) itself and the credentials passed along to the server. However, in certain cases, such as when the recipient address is a multicast group, or when the recipient is unable to communicate with the server in an out-of-band manner, this may not be possible. In these cases the server may chose another method such as a server-resident authorization list to ensure that the request originator has the proper credentials to request stream delivery to the recipient.

One solution that performs the necessary verification of acceptance of media suitable for unicast based delivery is the ICE based NAT traversal method described in [I-D.ietf-mmusic-rtsp-nat]. This mechanism uses random passwords and username so that the probability of unintended indication as a valid media destination is very low. In addition the server includes in its STUN requests a cookie (consisting of random material) that the destination echoes back, thus the solution also safe-guards against having an off-path attacker being able to spoof the STUN checks. This leaves this solution vulnerable only to on-path attackers that can see the STUN requests go to the target of attack and thus forge a response.

For delivery to multicast addresses there is a need for another solution which is not specified in this memo.

21.2.2. RTP Security analysis

RTP is a commonly used media transport protocol and has been the most common choice for RTSP 1.0 implementations. The core RTP protocol has been in use for a long time and it has well-known security properties and the RTP security consideration (Section 9 of [RFC3550]) needs to be reviewed. In perspective of the usage of RTP in context of RTSP the following properties should be noted:

Stream Additions:

RTP has support for multiple simultaneous media streams in each RTP session. As some use cases require support for non-synchronized adding and removal of media streams and their identifiers an attacker can easily insert additional media streams into a session context that according to protocol design is intended to be played out. Another threat vector is one of denial of service by exhausting the resources of the RTP session receiver, for example by using a large number of SSRC identifiers simultaneously. The strong mitigation of this is to ensure that one cryptographically authenticates any incoming packet flow to the RTP session. Weak mitigations like blocking additional media streams in session contexts easily lead to a denial of service vulnerability in addition to preventing certain RTP extensions or use cases which rely on multiple media streams, such as RTP retransmission [RFC4588] to function.

Forged Feedback:

The built in RTP control Protocol (RTCP) also offers a large attack surface for a couple of different types of attacks. One venue is to send RTCP feedback to the media sender indicating large amounts of packet loss and thus trigger a media bit-rate adaptation response from the sender resulting in lowered media quality and potentially shut down of the media stream. Another attack is to perform a resource exhaustion attack on the receiver by using many SSRC identifiers to create large state tables and increase the RTCP related processing demands.

RTP/RTCP Extensions:

RTP and RTCP extensions generally provide additional and sometimes extremely powerful tools to do denial of service or service disruption. For example the Code Control Message [RFC5104] RTCP extensions enables both locking down the bit-rate to low values and disrupt video quality by requesting Intra frames.

Taking into account the above general discussion in Section 21.2 and the RTP specific discussion in this section it is clear that strong security mechanism to protect RTP is necessary to support. Therefore this specification has the following requirements on RTP security functions for all RTSP agents that handles media streams and where the media stream transport is done using RTP.

RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and thus the SAVP profile. In addition the secure AVP profile (SAVPF) [RFC5124] MUST also be supported if the AVPF profile is implemented. This specification requires no additional crypto transforms or configuration values beyond the mandatory to implement in RFC3711, i.e. AES-CM and HMAC-SHA1. The default key-management mechanism which MUST be implemented is the one defined in the MIKEY Key Establishment [sec-mikey]. The MIKEY implementation MUST implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and in addition the SRTP parameter negotiation necessary to negotiate the supported SRTP transforms and parameters.

22. IANA Considerations

This section sets up a number of registries for RTSP 2.0 that should be maintained by IANA. These registries are separate from any registries existing for RTSP 1.0. For each registry there is a description of what it is required to contain, what specification is needed when adding an entry with IANA, and finally the entries that this document needs to register. See also the Section 2.7 "Extending RTSP". There is also an IANA registration of three SDP attributes.

Registries or entries in registries which have been made for RTSP 1.0 are not moved to RTSP 2.0. The registries and entries in registries of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry in a registry is also required in RTSP 2.0, it MUST follow the below defined procedure to allocate the registry or entry in a registry.

The sections describing how to register an item uses some of the requirements level described in RFC 5226 [RFC5226], namely "First Come, First Served", "Expert Review, "Specification Required", and "Standards Action".

In case a registry requires a contact person, the authors are the contact person for any entries created by this document.

A registration request to IANA MUST contain the following information:

• A name of the item to register according to the rules specified by the intended registry.
• Indication of who has change control over the feature (for example, IETF, ISO, ITU-T, other international standardization bodies, a consortium, a particular company or group of companies, or an individual);
• A reference to a further description, if available, for example (in decreasing order of preference) an RFC, a published standard, a published paper, a patent filing, a technical report, documented source code or a computer manual;
• For proprietary features, contact information (postal and email address);

22.1. Feature-tags

22.1.1. Description

When a client and server try to determine what part and functionality of the RTSP specification and any future extensions that its counter part implements there is need for a namespace. This registry contains named entries representing certain functionality.

The usage of feature-tags is explained in Section 11 and Section 13.1.

22.1.2. Registering New Feature-tags with IANA

The registering of feature-tags is done on a first come, first served basis.

The name of the feature MUST follow these rules: The name may be of any length, but SHOULD be no more than twenty characters long. The name MUST NOT contain any spaces, or control characters. The registration MUST indicate if the feature-tag applies to clients, servers, or proxies only or any combinations of these. Any proprietary feature MUST have as the first part of the name a vendor tag, which identifies the organization. The registry entries consist of the feature tag, a one paragraph description of what it represents, its applicability (server, client, proxy, any combination) and a reference to its specification where applicable.

Examples for a vendor tag describing a proprietary feature are:

vendorA.specfeat01

vendorA.specfeat02

22.1.3. Registered entries

The following feature-tags are defined in this specification and hereby registered. The change control belongs to the IETF.

play.basic:

The implementation for delivery and playback operations according to the core RTSP specification, as defined in this memo. Applies for both clients, servers and proxies.

play.scale:

Support of scale operations for media playback. Applies only for servers.

play.speed:

Support of the speed functionality for media delivery. Applies only for servers.

setup.rtp.rtcp.mux

Support of the RTP and RTCP multiplexing as discussed in Appendix C.1.6.4. Applies for both client and servers and any media caching proxy.

This should be represented by IANA as a table with the feature tags, contact person and their references.

22.2. RTSP Methods

22.2.1. Description

Methods are described in Section Section 13. Extending the protocol with new methods allow for totally new functionality.

22.2.2. Registering New Methods with IANA

A new method MUST be registered through an IETF Standards Action. The reason is that new methods may radically change the protocol's behavior and purpose.

A specification for a new RTSP method MUST consist of the following items:

• A method name which follows the ABNF rules for methods.
• A clear specification what a request using the method does and what responses are expected. Which directions the method is used, C->S or S->C or both. How the use of headers, if any, modifies the behavior and effect of the method.
• A list or table specifying which of the IANA registered headers that are allowed to be used with the method in request or/and response. The list or table SHOULD follow the format of tables in Section 18.
• Describe how the method relates to network proxies.

22.2.3. Registered Entries

This specification, RFCXXXX, registers 10 methods: DESCRIBE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. The initial table of the registry is provided below.

Method         Directionality           Reference
-----------------------------------------------------
DESCRIBE       C->S                     [RFCXXXX]
GET_PARAMETER  C->S, S->C               [RFCXXXX]
OPTIONS        C->S, S->C               [RFCXXXX]
PAUSE          C->S                     [RFCXXXX]
PLAY           C->S                     [RFCXXXX]
PLAY_NOTIFY    S->C                     [RFCXXXX]
REDIRECT       S->C                     [RFCXXXX]
SETUP          C->S                     [RFCXXXX]
SET_PARAMETER  C->S, S->C               [RFCXXXX]
TEARDOWN       C->S, S->C               [RFCXXXX] 

22.3. RTSP Status Codes

22.3.1. Description

A status code is the three digit number used to convey information in RTSP response messages, see Section 8. The number space is limited and care should be taken not to fill the space.

22.3.2. Registering New Status Codes with IANA

A new status code registration follows the policy of IETF Review. A specification for a new status code MUST specify the following:

• The registered number.
• A description of what the status code means and the expected behavior of the sender and receiver of the code.

22.3.3. Registered Entries

RFCXXXX, registers the numbered status code defined in the ABNF entry "Status-Code" except "extension-code" (that defines the syntax allowed for future extensions) in Section 20.2.2.

22.4. RTSP Headers

22.4.1. Description

By specifying new headers a method(s) can be enhanced in many different ways. An unknown header will be ignored by the receiving agent. If the new header is vital for a certain functionality, a feature-tag for the functionality can be created and demanded to be used by the counter-part with the inclusion of a Require header carrying the feature-tag.

22.4.2. Registering New Headers with IANA

Registrations in the registry can be done following the Expert Review policy. A specification SHOULD be provided, preferably an IETF RFC or other Standards Developing Organization specification. The minimal information in a registration request is the header name and the contact information.

The specification SHOULD contain the following information:

• The name of the header.
• An ABNF specification of the header syntax.
• A list or table specifying when the header may be used, encompassing all methods, their request or response, the direction (C->S or S->C).
• How the header is to be handled by proxies.
• A description of the purpose of the header.

22.4.3. Registered entries

All headers specified in Section 18 in RFCXXXX are to be registered. The Registry is to include header name and reference.

Furthermore the following legacy RTSP headers defined in other specifications are registered with header name, reference and description according to below list. Note: These references may not fulfill all of the above rules for registrations due to their legacy status.

• x-wap-profile defined in [TS-26234]. The x-wap-profile request header contains one or more absolute URLs to the requesting agent's device capability profile.
• x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff request header contains a subset of a device capability profile.
• x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-warning is a response header that contains error codes explaining to what extent the server has been able to match the terminal request in regards to device capability profile as described using x-wap-profile and x-wap-profile-diff headers.
• x-predecbufsize defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffer size.
• x-initpredecbufperiod defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffering period.
• x-initpostdecbufperiod defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 Annex G post-decoder buffering period.
• 3gpp-videopostdecbufsize defined in [TS-26234]. This response header provides an RTSP agent with the TS 26.234 defined post-decoder buffer size usable for H.264 (AVC) video streams.
• 3GPP-Link-Char defined in [TS-26234]. This request header provides the RTSP server with the RTSP client's link charateristics as deterimined from the radio interface. The information that can be provided are guaranteed bit-rate, maximum bit-rate and maximum transfer delay.
• 3GPP-Adaptation defined in [TS-26234]. This general header is part of the bit-rate adaptation solution specified for PSS. It provides the RTSP client's buffer sizes and target buffer levels to the server and responses are used to acknowledge the support and values.
• 3GPP-QoE-Metrics defined in [TS-26234]. This general header is used by PSS RTSP agents to negotiate the quality of experince metrics that a client should gather and report to the server.
• 3GPP-QoE-Feedback defined in [TS-26234]. This request header is used by RTSP clients supporting PSS to report the actual values of the metrics gathered in its quality of experince metering.

The use of "x-" is NOT RECOMMENDED but the above headers in the register list were defined prior to the clarification.

22.5. Accept-Credentials

The security framework's TLS connection mechanism has two registrable entities.

22.5.1. Accept-Credentials policies

In Section 19.3.1 three policies for how to handle certificates are specified. Further policies may be defined and MUST be registered with IANA using the following rules:

• Registering requires an IETF Standards Action
• A registration is required to name a contact person.
• Name of the policy.
• A describing text that explains how the policy works for handling the certificates.

This specification registers the following values:

Any

Proxy

User

22.5.2. Accept-Credentials hash algorithms

The Accept-Credentials header (See Section 18.2) allows for the usage of other algorithms for hashing the DER records of accepted entities. The registration of any future algorithm is expected to be extremely rare and could also cause interoperability problems. Therefore the bar for registering new algorithms is intentionally placed high.

Any registration of a new hash algorithm MUST fulfill the following requirement:

• Follow the IETF Standards Action policy.
• A definition of the algorithm and its identifier meeting the "token" ABNF requirement.

The registered value is:

Hash Alg. Id   Reference
------------------------
sha-256        [RFCXXXX]

22.6. Cache-Control Cache Directive Extensions

There exists a number of cache directives which can be sent in the Cache-Control header. A registry for these cache directives MUST be defined with the following rules:

• Registering requires an IETF Standards Action or IESG Approval.
• A registration is required to contain a contact person.
• Name of the directive and a definition of the value, if any.
• Specification if it is a request or response directive.
• A describing text that explains how the cache directive is used for RTSP controlled media streams.

This specification registers the following values:

no-cache:

public:

private:

no-transform:

only-if-cached:

max-stale:

min-fresh:

must-revalidate:

proxy-revalidate:

max-age:

The registry should be represented as: Name of the directive, contact person and reference.

22.7. Media Properties

22.7.1. Description

The media streams being controlled by RTSP can have many different properties. The media properties required to cover the use cases that were in mind when writing the specification are defined. However, it can be expected that further innovation will result in new use cases or media streams with properties not covered by the ones specified here. Thus new media properties can be specified. As new media properties may need a substantial amount of new definitions to correctly specify behavior for this property the bar is intended to be high.

22.7.2. Registration Rules

Registering a new media property MUST fulfill the following requirements

• Follow the Specification Required policy and get the approval of the designated Expert.
• Have an ABNF definition of the media property value name that meets "media-prop-ext" definition
• A Contact Person for the Registration
• Description of all changes to the behavior of the RTSP protocol as result of these changes.

22.7.3. Registered Values

This specification registers the 9 values listed in Section 18.28. The registry should be represented as: Name of the media property, contact person and reference.

22.8. Notify-Reason header

22.8.1. Description

Notify-Reason values are used for indicating the reason the notification was sent. Each reason has its associated rules on what headers and information that may or must be included in the notification. New notification behaviors need to be specified to enable interoperable usage, thus a specification of each new value is required.

22.8.2. Registration Rules

Registrations for new Notify-Reason value MUST fulfill the following requirements

• Follow the Specification Required policy and get the approval of the designated Expert.
• An ABNF definition of the Notify reason value name that meets "Notify-Reason-extension" definition
• A Contact Person for the Registration
• Description of which headers shall be included in the request and response, when it should be sent, and any effect it has on the server client state.

22.8.3. Registered Values

This specification registers 3 values defined in the Notify-Reas-val ABNF, Section 20.2.3:

end-of-stream:

This Notify-Reason value indicates the end of a media stream.

media-properties-update:

This Notify-Reason value allows the server to indicate that the properties of the media has changed during the playout.

scale-change:

This Notify-Reason value allows the server to notify the client about a change in the Scale of the media.

The registry entries should be represented in the registry as: Name, short description, contact and reference.

22.9. Range header formats

22.9.1. Description

The Range header [sec_Range] allows for different range formats. New ones may be registered, but moderation should be applied as it makes interoperability more difficult.

22.9.2. Registration Rules

A registration MUST fulfill the following requirements:

• Follow the Specification Required policy.
• An ABNF definition of the range format that fulfills the "range-ext" definition.
• A Contact person for the registration.
• Rules for how one handles the range when using a negative Scale.

22.9.3. Registered Values

The registry should be represented as: Name of the range format, contact person and reference. This specification registers the following values.

npt:

Normal Play Time

clock:

UTC Clock format

smpte:

SMPTE Timestamps

smpte-30-drop:

SMPTE Timestamps

smpte-25:

SMPTE Timestamps

22.10. Terminate-Reason Header

The Terminate-Reason header [sec_Terminate-Reason] has two registries for extensions.

22.10.1. Redirect Reasons

Registrations are done under the policy of Expert Review. The registered value needs to follow the Terminate-Reason ABNF, i.e., be a token. The specification needs to provide a definition of what procedures are to be followed when a client receives this redirect reason. This specification registers three values:

• Session-Timeout
• Server-Admin
• Internal-Error

The registry should be represented as: Name of the Redirect Reason, contact person and reference.

22.10.2. Terminate-Reason Header Parameters

Registrations are done under the policy of Specification Required. The registrations must define a syntax for the parameter that also follows the syntax allowed by the RTSP 2.0 specification. A contact person is also required. This specification registers:

• time
• user-msg

The registry should be represented as: Name of the Terminate Reason, contact person and reference.

22.11. RTP-Info header parameters

22.11.1. Description

The RTP-Info header [sec_RTP-Info] carries one or more parameter value pairs with information about a particular point in the RTP stream. RTP extensions or new usages may need new types of information. As RTP information that could be needed is likely to be generic enough and to maximize the interoperability, new registration requires Specification Required.

22.11.2. Registration Rules

Registrations for new RTP-Info value MUST fulfill the following requirements

• Follow the Specification Required policy and get the approval of the designated Expert.
• Have an ABNF definition that meets the "generic-param" definition
• A Contact Person for the Registration

22.11.3. Registered Values

This specification registers the following parameter value pairs:

• url
• ssrc
• seq
• rtptime

The registry should be represented as: Name of the parameter, contact person and reference.

22.12. Seek-Style Policies

22.12.1. Description

New seek policies may be registered, however, a large number of these will complicate implementation substantially. The impact of unknown policies is that the server will not honor the unknown and use the server default policy instead.

22.12.2. Registration Rules

Registrations of new Seek-Style polices MUST fulfill the following requirements

• Follow the Specification Required policy.
• Have an ABNF definition of the Seek-Style policy name that meets "Seek-S-value-ext" definition
• A Contact Person for the Registration
• Description of which headers shall be included in the request and response, when it should be sent, and any affect it has on the server client state.

22.12.3. Registered Values

This specification registers 4 values:

• RAP
• CoRAP
• First-Prior
• Next

The registry should be represented as: Name of the Seek-Style Policy, short description, contact person and reference.

22.13. Transport Header Registries

The transport header contains a number of parameters which have possibilities for future extensions. Therefore registries for these need to be defined.

22.13.1. Transport Protocol Specification

A registry for the parameter transport-protocol specification MUST be defined with the following rules:

• Registering uses the policy of Specification Required.
• A contact person or organization with address and email.
• A value definition that are following the ABNF syntax definition of "transport-id" Section 20.2.3.
• A describing text that explains how the registered value are used in RTSP.

The registry should be represented as: The protocol ID string, contact person and reference.

This specification registers the following values:

RTP/AVP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over UDP. The usage is explained in RFC XXXX, Appendix C.1.

RTP/AVP/UDP:

the same as RTP/AVP.

RTP/AVPF:

Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is explained in RFC XXXX, Appendix C.1.

RTP/AVPF/UDP:

the same as RTP/AVPF.

RTP/SAVP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over UDP. The usage is explained in RFC XXXX, Appendix C.1.

RTP/SAVP/UDP:

the same as RTP/SAVP.

RTP/SAVPF:

Use of the RTP[RFC3550] protocol for media transport in combination with the Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) [RFC5124] over UDP. The usage is explained in RFC XXXX, Appendix C.1.

RTP/SAVPF/UDP:

the same as RTP/SAVPF.

RTP/AVP/TCP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2.

RTP/AVPF/TCP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2.

RTP/SAVP/TCP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2.

RTP/SAVPF/TCP:

Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] over TCP. The usage is explained in RFC XXXX, Appendix C.2.2.

22.13.2. Transport modes

A registry for the transport parameter mode MUST be defined with the following rules:

• Registering requires an IETF Standards Action.
• A contact person or organization with address and email.
• A value definition that are following the ABNF "token" definition Section 20.2.3.
• A describing text that explains how the registered value are used in RTSP.

This specification registers 1 value:

PLAY:

See RFC XXXX.

22.13.3. Transport Parameters

A registry for parameters that may be included in the Transport header MUST be defined with the following rules: Section 18.52. This is a copy of this list:

• Registering uses the Specification Required policy.
• A value definition that are following the ABNF "token" definition Section 20.2.3.
• A describing text that explains how the registered value are used in RTSP.

This specification registers all the transport parameters defined in

• unicast
• multicast
• interleaved
• ttl
• layers
• ssrc
• mode
• dest_addr
• src_addr
• setup
• connection
• RTCP-mux
• MIKEY

22.14. URI Schemes

This specification defines two URI schemes ("rtsp" and "rtsps") and reserves a third one ("rtspu"). These URI schemes are defined in existing registries which are not created by RTSP. Registrations are following RFC 4395[RFC4395].

22.14.1. The rtsp URI Scheme

URI scheme name:

rtsp

Status:

Permanent

URI scheme syntax:

See Section 20.2.1 of RFC XXXX.

URI scheme semantics:

The rtsp scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP). RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.

Encoding considerations:

IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987.

Applications/protocols that use this URI scheme name:

RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX)

Interoperability considerations:

The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:

Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism.

A new relative format to use in the RTSP protocol elements that is not required to start with "/".

Security considerations:

All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.

Contact:

Magnus Westerlund, magnus.westerlund@ericsson.com

Author/Change controller:

IETF

References:

RFC 2326, RFC 3986, RFC 3987, RFC XXXX

22.14.2. The rtsps URI Scheme

URI scheme name:

rtsps

Status:

Permanent

URI scheme syntax:

See Section 20.2.1 of RFC XXXX.

URI scheme semantics:

The rtsps scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over TLS. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.

Encoding considerations:

IRIs in this scheme are defined and needs to be encoded as RTSP URIs when used within the RTSP protocol. That encoding is done according to RFC 3987.

Applications/protocols that use this URI scheme name:

RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC XXXX)

Interoperability considerations:

The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:

Support for IPV6 literal in host part and future IP literals through RFC 3986 defined mechanism.

A new relative format to use in the RTSP protocol elements that is not required to start with "/".

Security considerations:

All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.

Contact:

Magnus Westerlund, magnus.westerlund@ericsson.com

Author/Change controller:

IETF

References:

RFC 2326, RFC 3986, RFC 3987, RFC XXXX

22.14.3. The rtspu URI Scheme

URI scheme name:

rtspu

Status:

Permanent

URI scheme syntax:

See Section 3.2 of RFC 2326.

URI scheme semantics:

The rtspu scheme is used to indicate resources accessible through the usage of the Real-time Streaming Protocol (RTSP) over unreliable datagram transport. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are: DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN.

Encoding considerations:

IRIs in this scheme are not defined.

Applications/protocols that use this URI scheme name:

RTSP 1.0 (RFC 2326)

Interoperability considerations:

The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic.

Security considerations:

All the security threats identified in Section 7 of RFC 3986 apply also to this scheme. They needs to be reviewed and considered in any implementation utilizing this scheme.

Contact:

Magnus Westerlund, magnus.westerlund@ericsson.com

Author/Change controller:

IETF

References:

RFC 2326

22.15. SDP attributes

This specification defines three SDP [RFC4566] attributes that it is requested that IANA register.

SDP Attribute ("att-field"):

     Attribute name:     range
     Long form:          Media Range Attribute
     Type of name:       att-field
     Type of attribute:  Media and session level
     Subject to charset: No
     Purpose:            RFC XXXX
     Reference:          RFC XXXX, RFC 2326
     Values:             See ABNF definition.

     Attribute name:     control
     Long form:          RTSP control URI
     Type of name:       att-field
     Type of attribute:  Media and session level
     Subject to charset: No
     Purpose:            RFC XXXX
     Reference:          RFC XXXX, RFC 2326
     Values:             Absolute or Relative URIs.

     Attribute name:     mtag
     Long form:          Message Tag
     Type of name:       att-field
     Type of attribute:  Media and session level
     Subject to charset: No
     Purpose:            RFC XXXX
     Reference:          RFC XXXX
     Values:             See ABNF definition

22.16. Media Type Registration for text/parameters

Type name:

text

Subtype name:

parameters

Required parameters:

Optional parameters:

charset: The charset parameter is applicable to the encoding of the parameter values. The default charset is UTF-8, if the 'charset' parameter is not present.

Encoding considerations:

8bit

Security considerations:

This format may carry any type of parameters. Some can have security requirements, like privacy, confidentiality or integrity requirements. The format has no built in security protection. For the usage it was defined the transport can be protected between server and client using TLS. However, care must be taken to consider if also the proxies are trusted with the parameters in case hop-by-hop security is used. If stored as file in file systemi, the necessary precautions need to be taken in relation to the parameters requirements including object security such as S/MIME [RFC5751].

Interoperability considerations:

This media type was mentioned as a fictional example in [RFC2326], but was not formally specified. This has resulted in usage of this media type which may not match its formal definition.

Published specification:

RFC XXXX, Appendix F.

Applications that use this media type:

Applications that use RTSP and have additional parameters they like to read and set using the RTSP GET_PARAMETER and SET_PARAMETER methods.

Additional information:

Magic number(s):

File extension(s):

Macintosh file type code(s):

Person & email address to contact for further information:

Magnus Westerlund (magnus.westerlund@ericsson.com)

Intended usage:

Common

Restrictions on usage:

None

Author:

Magnus Westerlund (magnus.westerlund@ericsson.com)

Change controller:

IETF

Addition Notes:

23. References

23.1. Normative References

23.2. Informative References

Appendix A. Examples

This section contains several different examples trying to illustrate possible ways of using RTSP. The examples can also help with the understanding of how functions of RTSP work. However, remember that these are examples and the normative and syntax description in the other sections take precedence. Please also note that many of the examples contain syntax illegal line breaks to accommodate the formatting restriction that the RFC series impose.

A.1. Media on Demand (Unicast)

This is an example of media on demand streaming of a media stored in a container file. For purposes of this example, a container file is a storage entity in which multiple continuous media types pertaining to the same end-user presentation are present. In effect, the container file represents an RTSP presentation, with each of its components being RTSP controlled media streams. Container files are a widely used means to store such presentations. While the components are transported as independent streams, it is desirable to maintain a common context for those streams at the server end.

This enables the server to keep a single storage handle open easily. It also allows treating all the streams equally in case of any priorization of streams by the server.

It is also possible that the presentation author may wish to prevent selective retrieval of the streams by the client in order to preserve the artistic effect of the combined media presentation. Similarly, in such a tightly bound presentation, it is desirable to be able to control all the streams via a single control message using an aggregate URI.

The following is an example of using a single RTSP session to control multiple streams. It also illustrates the use of aggregate URIs. In a container file it is also desirable to not write any URI parts which are not kept, when the container is distributed, like the host and most of the path element. Therefore this example also uses the "*" and relative URI in the delivered SDP.

Also this presentation description (SDP) is not cachable, as the Expires header is set to an equal value with date indicating immediate expiration of its valididty.

Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
      CSeq: 1
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 1
      Server: PhonyServer/1.0
      Date: Thu, 24 Jan 1997 15:35:06 GMT
      Content-Type: application/sdp
      Content-Length: 271
      Content-Base: rtsp://example.com/twister.3gp/
      Expires: 24 Jan 1997 15:35:06 GMT

      v=0
      o=- 2890844256 2890842807 IN IP4 198.51.100.5
      s=RTSP Session
      i=An Example of RTSP Session Usage
      e=adm@example.com
      c=IN IP4 0.0.0.0
      a=control: *
      a=range: npt=0-0:10:34.10
      t=0 0
      m=audio 0 RTP/AVP 0
      a=control: trackID=1
      m=video 0 RTP/AVP 26
      a=control: trackID=4

C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
      CSeq: 2
      User-Agent: PhonyClient/1.2
      Require: play.basic
      Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
      Accept-Ranges: NPT, SMPTE, UTC

M->C: RTSP/2.0 200 OK
      CSeq: 2
      Server: PhonyServer/1.0
      Transport: RTP/AVP;unicast; ssrc=93CB001E;
                 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; 
                 src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
      Session: 12345678
      Expires: 24 Jan 1997 15:35:12 GMT
      Date: 24 Jan 1997 15:35:12 GMT
      Accept-Ranges: NPT
      Media-Properties: Random-Access=0.02, Immutable, Unlimited

C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Require: play.basic
      Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
      Session: 12345678
      Accept-Ranges: NPT, SMPTE, UTC


M->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/1.0
      Transport: RTP/AVP;unicast; ssrc=A813FC13;
                 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
                 src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
                 
      Session: 12345678
      Expires: 24 Jan 1997 15:35:13 GMT
      Date: 24 Jan 1997 15:35:13 GMT
      Accept-Range: NPT
      Media-Properties: Random-Access=0.8, Immutable, Unlimited

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
      CSeq: 4
      User-Agent: PhonyClient/1.2
      Range: npt=30-
      Seek-Style: RAP
      Session: 12345678

M->C: RTSP/2.0 200 OK
      CSeq: 4
      Server: PhonyServer/1.0
      Date: 24 Jan 1997 15:35:14 GMT
      Session: 12345678
      Range: npt=30-634.10
      Seek-Style: RAP
      RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
         ssrc=0D12F123:seq=12345;rtptime=3450012,
        url="rtsp://example.com/twister.3gp/trackID=1"
         ssrc=4F312DD8:seq=54321;rtptime=2876889

C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
      CSeq: 5
      User-Agent: PhonyClient/1.2
      Session: 12345678

# Pause happens 0.87 seconds after starting to play

M->C: RTSP/2.0 200 OK
      CSeq: 5
      Server: PhonyServer/1.0
      Date: 24 Jan 1997 15:36:01 GMT
      Session: 12345678
      Range: npt=30.87-634.10

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
      CSeq: 6
      User-Agent: PhonyClient/1.2
      Range: npt=30.87-634.10
      Seek-Style: Next
      Session: 12345678

M->C: RTSP/2.0 200 OK
      CSeq: 6
      Server: PhonyServer/1.0
      Date: 24 Jan 1997 15:36:01 GMT
      Session: 12345678
      Range: npt=30.87-634.10
      Seek-Style: Next
      RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
         ssrc=0D12F123:seq=12555;rtptime=6330012,
        url="rtsp://example.com/twister.3gp/trackID=1"
         ssrc=4F312DD8:seq=55021;rtptime=3132889


C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
      CSeq: 7
      User-Agent: PhonyClient/1.2
      Session: 12345678

M->C: RTSP/2.0 200 OK
      CSeq: 7
      Server: PhonyServer/1.0
      Date: 24 Jan 1997 15:49:34 GMT
     

A.2. Media on Demand using Pipelining

This example is basically the example above (Appendix A.1), but now utilizing pipelining to speed up the setup. It requires only two round trip times until the media starts flowing. First of all, the session description is retrieved to determine what media resources need to be setup. In the second step, one sends the necessary SETUP requests and the PLAY request to initiate media delivery.

Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.

C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
      CSeq: 1
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 1
      Server: PhonyServer/1.0
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Content-Type: application/sdp
      Content-Length: 271
      Content-Base: rtsp://example.com/twister.3gp/
      Expires: 24 Jan 1997 15:35:06 GMT

      v=0
      o=- 2890844256 2890842807 IN IP4 192.0.2.5
      s=RTSP Session
      i=An Example of RTSP Session Usage
      e=adm@example.com
      c=IN IP4 0.0.0.0
      a=control: *
      a=range: npt=0-0:10:34.10
      t=0 0
      m=audio 0 RTP/AVP 0
      a=control: trackID=1
      m=video 0 RTP/AVP 26
      a=control: trackID=4

C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
      CSeq: 2
      User-Agent: PhonyClient/1.2
      Require: play.basic
      Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
      Accept-Ranges: NPT, SMPTE, UTC
      Pipelined-Requests: 7654

C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Require: play.basic
      Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
      Accept-Ranges: NPT, SMPTE, UTC
      Pipelined-Requests: 7654

C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
      CSeq: 4
      User-Agent: PhonyClient/1.2
      Range: npt=0-
      Seek-Style: RAP
      Pipelined-Requests: 7654

M->C: RTSP/2.0 200 OK
      CSeq: 2
      Server: PhonyServer/1.0
      Transport: RTP/AVP;unicast;
                 dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
                 src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
                 ssrc=93CB001E
      Session: 12345678
      Expires: 24 Jan 1997 15:35:12 GMT
      Date: 23 Jan 1997 15:35:12 GMT
      Accept-Ranges: NPT
      Pipelined-Requests: 7654
      Media-Properties: Random-Access=0.2, Immutable, Unlimited

M->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/1.0
      Transport: RTP/AVP;unicast;
                 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
                 src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
                 ssrc=A813FC13
      Session: 12345678
      Expires: 24 Jan 1997 15:35:13 GMT
      Date: 23 Jan 1997 15:35:13 GMT
      Accept-Range: NPT
      Pipelined-Requests: 7654
      Media-Properties: Random-Access=0.8, Immutable, Unlimited

M->C: RTSP/2.0 200 OK
      CSeq: 4
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:35:14 GMT
      Session: 12345678
      Range: npt=0-623.10
      Seek-Style: RAP
      RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
         ssrc=0D12F123:seq=12345;rtptime=3450012,
        url="rtsp://example.com/twister.3gp/trackID=1"
         ssrc=4F312DD8:seq=54321;rtptime=2876889
      Pipelined-Requests: 7654

A.3. Media on Demand (Unicast)

An alternative example of media on demand with a bit more tweaks is the following. Client C requests a movie distributed from two different media servers A (audio.example.com) and V ( video.example.com). The media description is stored on a web server W. The media description contains descriptions of the presentation and all its streams, including the codecs that are available, dynamic RTP payload types, the protocol stack, and content information such as language or copyright restrictions. It may also give an indication about the timeline of the movie.

In this example, the client is only interested in the last part of the movie.

C->W: GET /twister.sdp HTTP/1.1
      Host: www.example.com
      Accept: application/sdp

W->C: HTTP/1.1 200 OK
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Content-Type: application/sdp
      Content-Length: 278
      Expires: 23 Jan 1998 15:35:06 GMT

      v=0
      o=- 2890844526 2890842807 IN IP4 198.51.100.5
      s=RTSP Session
      e=adm@example.com
      c=IN IP4 0.0.0.0
      a=range:npt=0-1:49:34
      t=0 0
      m=audio 0 RTP/AVP 0
      a=control:rtsp://audio.example.com/twister/audio.en
      m=video 0 RTP/AVP 31
      a=control:rtsp://video.example.com/twister/video

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
      CSeq: 1
      User-Agent: PhonyClient/1.2
      Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
                 RTP/AVP/TCP;unicast;interleaved=0-1
      Accept-Ranges: NPT, SMPTE, UTC

A->C: RTSP/2.0 200 OK
      CSeq: 1
      Session: 12345678
      Transport: RTP/AVP/UDP;unicast;
                 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
                 src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
      Date: 23 Jan 1997 15:35:12 GMT
      Server: PhonyServer/1.0
      Expires: 24 Jan 1997 15:35:12 GMT
      Cache-Control: public
      Accept-Ranges: NPT, SMPTE
      Media-Properties: Random-Access=0.02, Immutable, Unlimited

C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
      CSeq: 1
      User-Agent: PhonyClient/1.2
      Transport: RTP/AVP/UDP;unicast;
                 dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
                 RTP/AVP/TCP;unicast;interleaved=0-1
      Accept-Ranges: NPT, SMPTE, UTC

V->C: RTSP/2.0 200 OK
      CSeq: 1
      Session: 23456789
      Transport: RTP/AVP/UDP;unicast;
         dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
         src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
      Date: 23 Jan 1997 15:35:12 GMT
      Server: PhonyServer/1.0
      Cache-Control: public
      Expires: 24 Jan 1997 15:35:12 GMT
      Accept-Ranges: NPT, SMPTE
      Media-Properties: Random-Access=1.2, Immutable, Unlimited

C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
      CSeq: 2
      User-Agent: PhonyClient/1.2
      Session: 23456789
      Range: smpte=0:10:00-

V->C: RTSP/2.0 200 OK
      CSeq: 2
      Session: 23456789
      Range: smpte=0:10:00-1:49:23
      Seek-Style: First-Prior
      RTP-Info: url="rtsp://video.example.com/twister/video"
                ssrc=A17E189D:seq=12312232;rtptime=78712811
      Server: PhonyServer/2.0
      Date: 23 Jan 1997 15:35:13 GMT

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
      CSeq: 2
      User-Agent: PhonyClient/1.2
      Session: 12345678
      Range: smpte=0:10:00-

A->C: RTSP/2.0 200 OK
      CSeq: 2
      Session: 12345678
      Range: smpte=0:10:00-1:49:23
      Seek-Style: First-Prior
      RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
                ssrc=3D124F01:seq=876655;rtptime=1032181
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:35:13 GMT



C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Session: 12345678

A->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:36:52 GMT

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Session: 23456789

V->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/2.0
      Date: 23 Jan 1997 15:36:52 GMT

Even though the audio and video track are on two different servers that may start at slightly different times and may drift with respect to each other over time, the client can perform initial synchronization of the two media using RTP-Info and Range received in the PLAY responses. If the two servers are time synchronized the RTCP packets can also be used to maintain synchronization.

A.4. Single Stream Container Files

C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0
      Accept: application/x-rtsp-mh, application/sdp
      CSeq: 1
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 1
      Content-base: rtsp://foo.example.com/test.wav/
      Content-type: application/sdp
      Content-length: 163
      Server: PhonyServer/1.0
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Expires: 23 Jan 1997 17:00:00 GMT

      v=0
      o=- 872653257 872653257 IN IP4 192.0.2.5
      s=mu-law wave file
      i=audio test
      c=IN IP4 0.0.0.0
      t=0 0
      a=control: *
      m=audio 0 RTP/AVP 0
      a=control:streamid=0

C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0
      Transport: RTP/AVP/UDP;unicast;
         dest_addr=":6970"/":6971";mode="PLAY"
      CSeq: 2
      User-Agent: PhonyClient/1.2
      Accept-Ranges: NPT, SMPTE, UTC

S->C: RTSP/2.0 200 OK
      Transport: RTP/AVP/UDP;unicast;
          dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
          src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
          mode="PLAY";ssrc=EAB98712
      CSeq: 2
      Session: 2034820394
      Expires: 23 Jan 1997 16:00:00 GMT
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:35:07 GMT
      Accept-Ranges: NPT
      Media-Properties: Random-Acces=0.5, Immutable, Unlimited

C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Session: 2034820394

S->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:35:08 GMT
      Session: 2034820394
      Range: npt=0-600
      Seek-Style: RAP
      RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
         ssrc=0D12F123:seq=981888;rtptime=3781123

Some RTSP servers may treat all files as though they are "container files", yet other servers may not support such a concept. Because of this, clients needs to use the rules set forth in the session description for Request-URIs, rather than assuming that a consistent URI may always be used throughout. Below is an example of how a multi-stream server might expect a single-stream file to be served:

Note the different URI in the SETUP command, and then the switch back to the aggregate URI in the PLAY command. This makes complete sense when there are multiple streams with aggregate control, but is less than intuitive in the special case where the number of streams is one. However, the server has declared the aggregated control URI in the SDP and therefore this is legal.

C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Session: 2034820394

In this case, it is also required that servers accept implementations that use the non-aggregated interpretation and use the individual media URI, like this:

A.5. Live Media Presentation Using Multicast

C->W: GET /sessions.html HTTP/1.1
      Host: www.example.com

W->C: HTTP/1.1 200 OK
      Content-Type: text/html

      <html>
        ...
        <a href "rtsp://live.example.com/concert/audio"> 
           Streamed Live Music performance </a>           
        ...
      </html>

C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
      CSeq: 1
      Supported: play.basic, play.scale
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 1
      Content-Type: application/sdp
      Content-Length: 183
      Server: PhonyServer/1.0
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Supported: play.basic

      v=0
      o=- 2890844526 2890842807 IN IP4 192.0.2.5
      s=RTSP Session
      t=0 0
      m=audio 3456 RTP/AVP 0
      c=IN IP4 233.252.0.54/16
      a=control: rtsp://live.example.com/concert/audio
      a=range:npt=0-

C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
      CSeq: 2
      Transport: RTP/AVP;multicast;
           dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
      Accept-Ranges: NPT, SMPTE, UTC
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 2
      Server: PhonyServer/1.0
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Transport: RTP/AVP;multicast;
           dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
           ;ssrc=4D12AB92/0DF876A3
      Session: 0456804596
      Accept-Ranges: NPT, UTC
      Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0

C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
      CSeq: 3
      Session: 0456804596
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 3
      Server: PhonyServer/1.0
      Date: 23 Jan 1997 15:35:07 GMT
      Session: 0456804596
      Seek-Style: Next
      Range:npt=1256-
      RTP-Info: url="rtsp://live.example.com/concert/audio"
                ssrc=0D12F123:seq=1473; rtptime=80000

The media server M chooses the multicast address and port. Here, it is assumed that the web server only contains a pointer to the full description, while the media server M maintains the full description.

A.6. Capability Negotiation

C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
      CSeq: 1
      Supported: play.basic, play.scale
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 1
      Public: OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
      Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
      Server: PhonyServer/2.0
      Supported: play.basic, play.scale, com.example.flight

This example illustrates how the client and server determine their capability to support a special feature, in this case "play.scale". The server, through the clients request and the included Supported header, learns the client supports RTSP 2.0, and also supports the playback time scaling feature of RTSP. The server's response contains the following feature related information to the client; it supports the basic media delivery functions (play.basic), the extended functionality of time scaling of content (play.scale), and one "example.com" proprietary feature (com.example.flight). The client also learns the methods supported (Public header) by the server for the indicated resource.

C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
      CSeq: 3
      User-Agent: PhonyClient/1.2
      Transport: RTP/AVP/UDP;unicast;
                 dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
                 RTP/AVP/TCP;unicast;interleaved=0-1
      Require: play.scale
      Accept-Ranges: NPT, SMPTE, UTC
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 3
      Session: 12345678
      Transport: RTP/AVP/UDP;unicast;
         dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
         src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
      Server: PhonyServer/2.0
      Accept-Ranges: NPT, SMPTE
      Media-Properties: Random-Access=0.8, Immutable, Unlimited

When the client sends its SETUP request it tells the server that it requires support of the play.scale feature for this session by including the Require header.

Appendix B. RTSP Protocol State Machine

The RTSP session state machine describes the behavior of the protocol from RTSP session initialization through RTSP session termination.

The State machine is defined on a per session basis which is uniquely identified by the RTSP session identifier. The session may contain one or more media streams depending on state. If a single media stream is part of the session it is in non-aggregated control. If two or more is part of the session it is in aggregated control.

The below state machine is an informative description of the protocols behavior. In case of ambiguity with the earlier parts of this specification, the description in the earlier parts take precedence.

B.1. States

The state machine contains three states, described below. For each state there exists a table which shows which requests and events are allowed and whether they will result in a state change.

Init:

Initial state no session exists.

Ready:

Session is ready to start playing.

Play:

Session is playing, i.e. sending media stream data in the direction S->C.

B.2. State variables

This representation of the state machine needs more than its state to work. A small number of variables are also needed and they are explained below.

NRM:

The number of media streams part of this session.

RP:

Resume point, the point in the presentation time line at which a request to continue playing will resume from. A time format for the variable is not mandated.

B.3. Abbreviations

To make the state tables more compact a number of abbreviations are used, which are explained below.

IFI:

IF Implemented.

md:

Media

PP:

Pause Point, the point in the presentation time line at which the presentation was paused.

Prs:

Presentation, the complete multimedia presentation.

RedP:

Redirect Point, the point in the presentation time line at which a REDIRECT was specified to occur.

SES:

Session.

B.4. State Tables

This section contains a table for each state. The table contains all the requests and events that this state is allowed to act on. The events which are method names are, unless noted, requests with the given method in the direction client to server (C->S). In some cases there exist one or more requisite. The response column tells what type of response actions should be performed. Possible actions that are requested for an event include: response codes, e.g., 200, headers that need to be included in the response, setting of state variables, or setting of other session related parameters. The new state column tells which state the state machine changes to.

The response to a valid request meeting the requisites is normally a 2xx (SUCCESS) unless otherwise noted in the response column. The exceptions need to be given a response according to the response column. If the request does not meet the requisite, is erroneous or some other type of error occurs, the appropriate response code is to be sent. If the response code is a 4xx the session state is unchanged. A response code of 3rr will result in that the session is ended and its state is changed to Init. A response code of 304 results in no state change. However, there are restrictions to when a 3rr response may be used. A 5xx response does not result in any change of the session state, except if the error is not possible to recover from. A unrecoverable error results in the ending of the session. As it in the general case can't be determined if it was a unrecoverable error or not the client will be required to test. In the case that the next request after a 5xx is responded with 454 (Session Not Found) the client knows that the session has ended. For any request message that cannot be responded to within the time defined in Section 10.4, a 100 response must be sent.

The server will timeout the session after the period of time specified in the SETUP response, if no activity from the client is detected. Therefore there exists a timeout event for all states except Init.

In the case that NRM = 1 the presentation URI is equal to the media URI or a specified presentation URI. For NRM > 1 the presentation URI needs to be other than any of the medias that are part of the session. This applies to all states.

   C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2

   M->C: RTSP/2.0 200 OK
         CSeq: 1
         Server: PhonyServer/1.0
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Content-Type: application/sdp
         Content-Length: 227
         Content-Base: rtsp://example.com/twister.3gp/
         Expires: 24 Jan 1997 15:35:06 GMT

         v=0
         o=- 2890844256 2890842807 IN IP4 198.51.100.34
         s=RTSP Session
         i=An Example of RTSP Session Usage
         e=adm@example.com
         c=IN IP4 0.0.0.0
         a=control: *
         a=range: npt=0-0:10:34.10
         t=0 0
         m=audio 0 RTP/AVP 0
         a=control: trackID=1

   C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
         CSeq: 2
         User-Agent: PhonyClient/1.2
         Require: play.basic
         Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
                    setup=active;connection=new
         Accept-Ranges: NPT, SMPTE, UTC

   M->C: RTSP/2.0 200 OK
         CSeq: 2
         Server: PhonyServer/1.0
         Transport: RTP/AVP/TCP;unicast;
                    dest_addr=":9"/":9";
                    src_addr="198.51.100.5:53478"/"198.51.100:54091";
                    setup=passive;connection=new;ssrc=93CB001E
         Session: 12345678
         Expires: 24 Jan 1997 15:35:12 GMT
         Date: 23 Jan 1997 15:35:12 GMT
         Accept-Ranges: NPT
         Media-Properties: Random-Access=0.8, Immutable, Unlimited

   C->M: TCP Connection Establishment x2

   C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
         CSeq: 4
         User-Agent: PhonyClient/1.2
         Range: npt=30-
         Session: 12345678

   M->C: RTSP/2.0 200 OK
         CSeq: 4
         Server: PhonyServer/1.0
         Date: 23 Jan 1997 15:35:14 GMT
         Session: 12345678
         Range: npt=30-623.10
         Seek-Style: First-Prior
         RTP-Info:  url="rtsp://example.com/twister.3gp/trackID=1"
            ssrc=4F312DD8:seq=54321;rtptime=2876889

   C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
     CSeq: 4
     Session: abcdefgh
     Range: npt=10-15
     User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
     CSeq: 4
     Session: abcdefgh
     Range: npt=10-15
     RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
               ssrc=0D12F123:seq=0;rtptime=0

   S -> C: RTP packet - seq = 0,  rtptime = 0,     NPT time = 10s
   S -> C: RTP packet - seq = 1,  rtptime = 800,   NPT time = 10.1s
    . . .
   S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
           CSeq: 5
           Notify-Reason: end-of-stream
           Request-Status: cseq=4 status=200 reason="OK"
           Range: npt=-15
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
              ssrc=0D12F123:seq=49;rtptime=39200
           Session: abcdefgh

     C->S: RTSP/2.0 200 OK
           CSeq: 5
           User-Agent: PhonyClient/1.2

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
      CSeq: 6
      Session: abcdefg
      Range: npt=18-20
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 6
      Session: abcdefg
      Range: npt=18-20
      RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                ssrc=0D12F123:seq=50;rtptime=40100

   S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
   S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
    . . .
   S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
      CSeq: 4
      Session: abcdefg
      Range: npt=10-15

      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 4
      Session: abcdefg
      Range: npt=10-15
      RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                ssrc=0D12F123:seq=0;rtptime=0

   S -> C: RTP packet - seq = 0, rtptime = 0,    NPT time = 10s
   S -> C: RTP packet - seq = 1, rtptime = 800,  NPT time = 10.1s
   S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
   S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s

C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
      CSeq: 5
      Session: abcdefg
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 5
      Session: abcdefg
      Range: npt=10.4-15

C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
      CSeq: 6
      Session: abcdefg
      User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK
      CSeq: 6
      Session: abcdefg
      Range: npt=10.4-15
      RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
                ssrc=0D12F123:seq=4;rtptime=164400

   S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
   S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
   S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s

  a=control:rtsp://example.com/foo

  m=audio 0 RTP/AVP 31

  a=range:npt=0-34.4368
  a=range:clock=19971113T211503Z-19971113T220300Z
  Non seekable stream of unknown duration:
  a=range:npt=0-

  a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"

v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.example.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.example.com/movie.vid

C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
      CSeq: 1
      User-Agent: PhonyClient/1.2

M->C: RTSP/2.0 200 OK
      CSeq: 1
      Date: Thu, 23 Jan 1997 15:35:06 GMT
      Expires: Thu, 23 Jan 1997 16:35:06 GMT
      Content-Type: application/sdp
      Content-Base: rtsp://example.com/movie/
      Content-Length: 227

      v=0
      o=- 2890844256 2890842807 IN IP4 192.0.2.211
      s=I contain
      i=<more info>
      e=adm@example.com
      c=IN IP4 0.0.0.0
      a=control:*
      t=0 0
      m=video 8002 RTP/AVP 31
      a=control:trackID=1
      m=audio 8004 RTP/AVP 3
      a=control:trackID=2

file             = *((parameter / parameter-value) CRLF)
parameter        = 1*visible-except-colon 
parameter-value  = parameter *WSP ":" value 
visible-except-colon = %x21-39 / %x3B-7E    ; VCHAR - ":" 
value            = *(TEXT-UTF8char / WSP)
TEXT-UTF8char    =  %x21-7E / UTF8-NONASCII
UTF8-NONASCII    =  %xC0-DF 1UTF8-CONT
                 /  %xE0-EF 2UTF8-CONT
                 /  %xF0-F7 3UTF8-CONT
                 /  %xF8-FB 4UTF8-CONT
                 /  %xFC-FD 5UTF8-CONT
UTF8-CONT        =  %x80-BF
WSP              = <See RFC 5234> ; Space or HTAB
VCHAR            = <See RFC 5234>
CRLF             = <See RFC 5234>