Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 7826

 
 
 

Real-Time Streaming Protocol Version 2.0

Part 3 of 13, p. 35 to 60
Prev Section       Next Section

 


prevText      Top      ToC       Page 35 
5.  RTSP Message

   RTSP is a text-based protocol that uses the ISO 10646 character set
   in UTF-8 encoding per RFC 3629 [RFC3629].  Lines MUST be terminated
   by a CRLF.

      Text-based protocols make it easier to add optional parameters in
      a self-describing manner.  Since the number of parameters and the
      frequency of commands is low, processing efficiency is not a
      concern.  Text-based protocols, if used carefully, also allow easy
      implementation of research prototypes in scripting languages such
      as Python, PHP, Perl and TCL.

   The ISO 10646 character set avoids character-set switching, but is
   invisible to the application as long as US-ASCII is being used.  This
   is also the encoding used for text fields in RTCP [RFC3550].

   A request contains a method, the object the method is operating upon,
   and parameters to further describe the method.  Methods are
   idempotent unless otherwise noted.  Methods are also designed to
   require little or no state maintenance at the media server.

Top      Up      ToC       Page 36 
5.1.  Message Types

   RTSP messages are either requests from client to server or from
   server to client, and responses in the reverse direction.  Request
   (Section 7) and response (Section 8) messages use a format based on
   the generic message format of RFC 5322 [RFC5322] for transferring
   bodies (the payload of the message).  Both types of messages consist
   of a start-line, zero or more header fields (also known as
   "headers"), an empty line (i.e., a line with nothing preceding the
   CRLF) indicating the end of the headers, and possibly the data of the
   message body.  The ABNF [RFC5234] below is for illustration only; the
   formal message specification is presented in Section 20.2.2.

   generic-message = start-line
                   *(rtsp-header CRLF)
                     CRLF
                   [ message-body-data ]
   start-line = Request-Line / Status-Line

   In the interest of robustness, agents MUST ignore any empty line(s)
   received where a Request-Line or Status-Line is expected.  In other
   words, if the agent is reading the protocol stream at the beginning
   of a message and receives any number of CRLFs first, it MUST ignore
   all of the CRLFs.

5.2.  Message Headers

   RTSP header fields (see Section 18) include general-header, request-
   header, response-header, and message body header fields.

   The order in which header fields with differing field names are
   received is not significant.  However, it is "good practice" to send
   general-header fields first, followed by a request-header or
   response-header field, and ending with the message body header
   fields.

   Multiple header fields with the same field-name MAY be present in a
   message if and only if the entire field-value for that header field
   is defined as a comma-separated list.  It MUST be possible to combine
   the multiple header fields into one "field-name: field-value" pair,
   without changing the semantics of the message, by appending each
   subsequent field-value to the first, each separated by a comma.  The
   order in which header fields with the same field-name are received is
   therefore significant to the interpretation of the combined field
   value; thus, a proxy MUST NOT change the order of these field-values
   when a message is forwarded.

Top      Up      ToC       Page 37 
   Unknown message headers MUST be ignored (skipping over the header to
   the next protocol element, and not causing an error) by an RTSP
   server or client.  An RTSP proxy MUST forward unknown message
   headers.  Message headers defined outside of this specification that
   are required to be interpreted by the RTSP agent will need to use
   feature tags (Section 4.5) and include them in the appropriate
   Require (Section 18.43) or Proxy-Require (Section 18.37) header.

5.3.  Message Body

   The message body (if any) of an RTSP message is used to carry further
   information for a particular resource associated with the request or
   response.  An example of a message body is an SDP message.

   The presence of a message body in either a request or a response MUST
   be signaled by the inclusion of a Content-Length header (see
   Section 18.17) and Content-Type header (see Section 18.19).  A
   message body MUST NOT be included in a request or response if the
   specification of the particular method (see Method Definitions
   (Section 13)) does not allow sending a message body.  In case a
   message body is received in a message when not expected, the message
   body data SHOULD be discarded.  This is to allow future extensions to
   define optional use of a message body.

5.4.  Message Length

   An RTSP message that does not contain any message body is terminated
   by the first empty line after the header fields (note: an empty line
   is a line with nothing preceding the CRLF.).  In RTSP messages that
   contain message bodies, the empty line is followed by the message
   body.  The length of that body is determined by the value of the
   Content-Length header (Section 18.17).  The value in the header
   represents the length of the message body in octets.  If this header
   field is not present, a value of zero is assumed, i.e., no message
   body present in the message.  Unlike an HTTP message, an RTSP message
   MUST contain a Content-Length header whenever it contains a message
   body.  Note that RTSP does not support the HTTP/1.1 "chunked"
   transfer coding (see Section 4.1 of [RFC7230]).

      Given the moderate length of presentation descriptions returned,
      the server should always be able to determine its length, even if
      it is generated dynamically, making the chunked transfer encoding
      unnecessary.

6.  General-Header Fields

   General headers are headers that may be used in both requests and
   responses.  The general-headers are listed in Table 1:

Top      Up      ToC       Page 38 
                  +--------------------+----------------+
                  | Header Name        | Defined in     |
                  +--------------------+----------------+
                  | Accept-Ranges      | Section 18.5   |
                  |                    |                |
                  | Cache-Control      | Section 18.11  |
                  |                    |                |
                  | Connection         | Section 18.12  |
                  |                    |                |
                  | CSeq               | Section 18.20  |
                  |                    |                |
                  | Date               | Section 18.21  |
                  |                    |                |
                  | Media-Properties   | Section 18.29  |
                  |                    |                |
                  | Media-Range        | Section 18.30  |
                  |                    |                |
                  | Pipelined-Requests | Section 18.33  |
                  |                    |                |
                  | Proxy-Supported    | Section 18.38  |
                  |                    |                |
                  | Range              | Section 18.40  |
                  |                    |                |
                  | RTP-Info           | Section 18.45  |
                  |                    |                |
                  | Scale              | Section 18.46  |
                  |                    |                |
                  | Seek-Style         | Section 18.47  |
                  |                    |                |
                  | Server             | Section 18.48  |
                  |                    |                |
                  | Session            | Section 18.49  |
                  |                    |                |
                  | Speed              | Section 18.50  |
                  |                    |                |
                  | Supported          | Section 18.51  |
                  |                    |                |
                  | Timestamp          | Section 18.53  |
                  |                    |                |
                  | Transport          | Section 18.54  |
                  |                    |                |
                  | User-Agent         | Section 18.56  |
                  |                    |                |
                  | Via                | Section 18.57  |
                  +--------------------+----------------+

                 Table 1: The General Headers Used in RTSP

Top      Up      ToC       Page 39 
7.  Request

   A request message uses the format outlined below regardless of the
   direction of a request, whether client to server or server to client:

   o  Request line, containing the method to be applied to the resource,
      the identifier of the resource, and the protocol version in use;

   o  Zero or more Header lines, which can be of the following types:
      general-headers (Section 6), request-headers (Section 7.2), or
      message body headers (Section 9.1);

   o  One empty line (CRLF) to indicate the end of the header section;

   o  Optionally, a message body, consisting of one or more lines.  The
      length of the message body in octets is indicated by the Content-
      Length message header.

Top      Up      ToC       Page 40 
7.1.  Request Line

   The request line provides the key information about the request: what
   method, on what resources, and using which RTSP version.  The methods
   that are defined by this specification are listed in Table 2.

                    +---------------+----------------+
                    | Method        | Defined in     |
                    +---------------+----------------+
                    | DESCRIBE      | Section 13.2   |
                    |               |                |
                    | GET_PARAMETER | Section 13.8   |
                    |               |                |
                    | OPTIONS       | Section 13.1   |
                    |               |                |
                    | PAUSE         | Section 13.6   |
                    |               |                |
                    | PLAY          | Section 13.4   |
                    |               |                |
                    | PLAY_NOTIFY   | Section 13.5   |
                    |               |                |
                    | REDIRECT      | Section 13.10  |
                    |               |                |
                    | SETUP         | Section 13.3   |
                    |               |                |
                    | SET_PARAMETER | Section 13.9   |
                    |               |                |
                    | TEARDOWN      | Section 13.7   |
                    +---------------+----------------+

                         Table 2: The RTSP Methods

   The syntax of the RTSP request line has the following:

      <Method> SP <Request-URI> SP <RTSP-Version> CRLF

   Note: This syntax cannot be freely changed in future versions of
   RTSP.  This line needs to remain parsable by older RTSP
   implementations since it indicates the RTSP version of the message.

   In contrast to HTTP/1.1 [RFC7230], RTSP requests identify the
   resource through an absolute RTSP URI (including scheme, host, and
   port) (see Section 4.2) rather than just the absolute path.

      HTTP/1.1 requires servers to understand the absolute URI, but
      clients are supposed to use the Host request-header.  This is
      purely needed for backward compatibility with HTTP/1.0 servers, a
      consideration that does not apply to RTSP.

Top      Up      ToC       Page 41 
   An asterisk "*" can be used instead of an absolute URI in the
   Request-URI part to indicate that the request does not apply to a
   particular resource but to the server or proxy itself, and is only
   allowed when the request method does not necessarily apply to a
   resource.

   For example:

      OPTIONS * RTSP/2.0

   An OPTIONS in this form will determine the capabilities of the server
   or the proxy that first receives the request.  If the capability of
   the specific server needs to be determined, without regard to the
   capability of an intervening proxy, the server should be addressed
   explicitly with an absolute URI that contains the server's address.

   For example:

      OPTIONS rtsp://example.com RTSP/2.0

Top      Up      ToC       Page 42 
7.2.  Request-Header Fields

   The RTSP headers in Table 3 can be included in a request, as request-
   headers, to modify the specifics of the request.

                 +---------------------+----------------+
                 | Header              | Defined in     |
                 +---------------------+----------------+
                 | Accept              | Section 18.1   |
                 |                     |                |
                 | Accept-Credentials  | Section 18.2   |
                 |                     |                |
                 | Accept-Encoding     | Section 18.3   |
                 |                     |                |
                 | Accept-Language     | Section 18.4   |
                 |                     |                |
                 | Authorization       | Section 18.8   |
                 |                     |                |
                 | Bandwidth           | Section 18.9   |
                 |                     |                |
                 | Blocksize           | Section 18.10  |
                 |                     |                |
                 | From                | Section 18.23  |
                 |                     |                |
                 | If-Match            | Section 18.24  |
                 |                     |                |
                 | If-Modified-Since   | Section 18.25  |
                 |                     |                |
                 | If-None-Match       | Section 18.26  |
                 |                     |                |
                 | Notify-Reason       | Section 18.32  |
                 |                     |                |
                 | Proxy-Authorization | Section 18.36  |
                 |                     |                |
                 | Proxy-Require       | Section 18.37  |
                 |                     |                |
                 | Referrer            | Section 18.41  |
                 |                     |                |
                 | Request-Status      | Section 18.42  |
                 |                     |                |
                 | Require             | Section 18.43  |
                 |                     |                |
                 | Terminate-Reason    | Section 18.52  |
                 +---------------------+----------------+

                     Table 3: The RTSP Request-Headers

   Detailed header definitions are provided in Section 18.

Top      Up      ToC       Page 43 
   New request-headers may be defined.  If the receiver of the request
   is required to understand the request-header, the request MUST
   include a corresponding feature tag in a Require or Proxy-Require
   header to ensure the processing of the header.

8.  Response

   After receiving and interpreting a request message, the recipient
   responds with an RTSP response message.  Normally, there is only one,
   final, response.  Responses using the response code class 1xx is the
   only class for which there MAY be sent one or more responses prior to
   the final response message.

   The valid response codes and the methods they can be used with are
   listed in Table 4.

8.1.  Status-Line

   The first line of a response message is the Status-Line, consisting
   of the protocol version followed by a numeric status code and the
   textual phrase associated with the status code, with each element
   separated by SP characters.  No CR or LF is allowed except in the
   final CRLF sequence.

   <RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF

8.1.1.  Status Code and Reason Phrase

   The Status-Code element is a 3-digit integer result code of the
   attempt to understand and satisfy the request.  These codes are fully
   defined in Section 17.  The reason phrase is intended to give a short
   textual description of the Status-Code.  The Status-Code is intended
   for use by automata and the reason phrase is intended for the human
   user.  The client is not required to examine or display the reason
   phrase.

   The first digit of the Status-Code defines the class of response.
   The last two digits do not have any categorization role.  There are
   five values for the first digit:

   1xx:  Informational - Request received, continuing process

   2xx:  Success - The action was successfully received, understood, and
         accepted

   3rr:  Redirection - Further action needs to be taken in order to
         complete the request (3rr rather than 3xx is used as 304 is
         excluded; see Section 17.3)

Top      Up      ToC       Page 44 
   4xx:  Client Error - The request contains bad syntax or cannot be
         fulfilled

   5xx:  Server Error - The server failed to fulfill an apparently valid
         request

   The individual values of the numeric status codes defined for RTSP
   2.0, and an example set of corresponding reason phrases, are
   presented in Table 4.  The reason phrases listed here are only
   recommended; they may be replaced by local equivalents without
   affecting the protocol.  Note that RTSP adopted most HTTP/1.1
   [RFC2068] status codes and then added RTSP-specific status codes
   starting at x50 to avoid conflicts with future HTTP status codes that
   are desirable to import into RTSP.  All these codes are RTSP specific
   and RTSP has its own registry separate from HTTP for status codes.

   RTSP status codes are extensible.  RTSP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable.  However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with an exception for unknown 3xx
   codes, which MUST be treated as a 302 (Found).  The reason for that
   exception is that the status code 300 (Multiple Choices in HTTP) is
   not defined for RTSP.  A response with an unrecognized status code
   MUST NOT be cached.  For example, if an unrecognized status code of
   431 is received by the client, it can safely assume that there was
   something wrong with its request and treat the response as if it had
   received a 400 status code.  In such cases, user agents SHOULD
   present to the user the message body returned with the response,
   since that message body is likely to include human-readable
   information that will explain the unusual status.

   +------+---------------------------------+--------------------------+
   | Code | Reason                          | Method                   |
   +------+---------------------------------+--------------------------+
   | 100  | Continue                        | all                      |
   |      |                                 |                          |
   | 200  | OK                              | all                      |
   |      |                                 |                          |
   | 301  | Moved Permanently               | all                      |
   |      |                                 |                          |
   | 302  | Found                           | all                      |
   |      |                                 |                          |
   | 303  | See Other                       | n/a                      |
   |      |                                 |                          |
   | 304  | Not Modified                    | all                      |
   |      |                                 |                          |

Top      Up      ToC       Page 45 
   | 305  | Use Proxy                       | all                      |
   |      |                                 |                          |
   | 400  | Bad Request                     | all                      |
   |      |                                 |                          |
   | 401  | Unauthorized                    | all                      |
   |      |                                 |                          |
   | 402  | Payment Required                | all                      |
   |      |                                 |                          |
   | 403  | Forbidden                       | all                      |
   |      |                                 |                          |
   | 404  | Not Found                       | all                      |
   |      |                                 |                          |
   | 405  | Method Not Allowed              | all                      |
   |      |                                 |                          |
   | 406  | Not Acceptable                  | all                      |
   |      |                                 |                          |
   | 407  | Proxy Authentication Required   | all                      |
   |      |                                 |                          |
   | 408  | Request Timeout                 | all                      |
   |      |                                 |                          |
   | 410  | Gone                            | all                      |
   |      |                                 |                          |
   | 412  | Precondition Failed             | DESCRIBE, SETUP          |
   |      |                                 |                          |
   | 413  | Request Message Body Too Large  | all                      |
   |      |                                 |                          |
   | 414  | Request-URI Too Long            | all                      |
   |      |                                 |                          |
   | 415  | Unsupported Media Type          | all                      |
   |      |                                 |                          |
   | 451  | Parameter Not Understood        | SET_PARAMETER,           |
   |      |                                 | GET_PARAMETER            |
   |      |                                 |                          |
   | 452  | reserved                        | n/a                      |
   |      |                                 |                          |
   | 453  | Not Enough Bandwidth            | SETUP                    |
   |      |                                 |                          |
   | 454  | Session Not Found               | all                      |
   |      |                                 |                          |
   | 455  | Method Not Valid in This State  | all                      |
   |      |                                 |                          |
   | 456  | Header Field Not Valid for      | all                      |
   |      | Resource                        |                          |
   |      |                                 |                          |
   | 457  | Invalid Range                   | PLAY, PAUSE              |
   |      |                                 |                          |
   | 458  | Parameter Is Read-Only          | SET_PARAMETER            |
   |      |                                 |                          |

Top      Up      ToC       Page 46 
   | 459  | Aggregate Operation Not Allowed | all                      |
   |      |                                 |                          |
   | 460  | Only Aggregate Operation        | all                      |
   |      | Allowed                         |                          |
   |      |                                 |                          |
   | 461  | Unsupported Transport           | all                      |
   |      |                                 |                          |
   | 462  | Destination Unreachable         | all                      |
   |      |                                 |                          |
   | 463  | Destination Prohibited          | SETUP                    |
   |      |                                 |                          |
   | 464  | Data Transport Not Ready Yet    | PLAY                     |
   |      |                                 |                          |
   | 465  | Notification Reason Unknown     | PLAY_NOTIFY              |
   |      |                                 |                          |
   | 466  | Key Management Error            | all                      |
   |      |                                 |                          |
   | 470  | Connection Authorization        | all                      |
   |      | Required                        |                          |
   |      |                                 |                          |
   | 471  | Connection Credentials Not      | all                      |
   |      | Accepted                        |                          |
   |      |                                 |                          |
   | 472  | Failure to Establish Secure     | all                      |
   |      | Connection                      |                          |
   |      |                                 |                          |
   | 500  | Internal Server Error           | all                      |
   |      |                                 |                          |
   | 501  | Not Implemented                 | all                      |
   |      |                                 |                          |
   | 502  | Bad Gateway                     | all                      |
   |      |                                 |                          |
   | 503  | Service Unavailable             | all                      |
   |      |                                 |                          |
   | 504  | Gateway Timeout                 | all                      |
   |      |                                 |                          |
   | 505  | RTSP Version Not Supported      | all                      |
   |      |                                 |                          |
   | 551  | Option Not Supported            | all                      |
   |      |                                 |                          |
   | 553  | Proxy Unavailable               | all                      |
   +------+---------------------------------+--------------------------+

          Table 4: Status Codes and Their Usage with RTSP Methods

Top      Up      ToC       Page 47 
8.2.  Response Headers

   The response-headers allow the request recipient to pass additional
   information about the response that cannot be placed in the Status-
   Line.  This header gives information about the server and about
   further access to the resource identified by the Request-URI.  All
   headers currently classified as response-headers are listed in
   Table 5.

                +------------------------+----------------+
                | Header                 | Defined in     |
                +------------------------+----------------+
                | Authentication-Info    | Section 18.7   |
                |                        |                |
                | Connection-Credentials | Section 18.13  |
                |                        |                |
                | Location               | Section 18.28  |
                |                        |                |
                | MTag                   | Section 18.31  |
                |                        |                |
                | Proxy-Authenticate     | Section 18.34  |
                |                        |                |
                | Public                 | Section 18.39  |
                |                        |                |
                | Retry-After            | Section 18.44  |
                |                        |                |
                | Unsupported            | Section 18.55  |
                |                        |                |
                | WWW-Authenticate       | Section 18.58  |
                +------------------------+----------------+

                    Table 5: The RTSP Response Headers

   Response-header names can be extended reliably only in combination
   with a change in the protocol version.  However, the usage of feature
   tags in the request allows the responding party to learn the
   capability of the receiver of the response.  A new or experimental
   header can be given the semantics of response-header if all parties
   in the communication recognize them to be a response-header.
   Unrecognized headers in responses MUST be ignored.

9.  Message Body

   Some request and response messages include a message body, if not
   otherwise restricted by the request method or response status code.
   The message body consists of the content data itself (see also
   Section 5.3).

Top      Up      ToC       Page 48 
   The SET_PARAMETER and GET_PARAMETER requests and responses, and the
   DESCRIBE response as defined by this specification, can have a
   message body; the purpose of the message body is defined in each
   case.  All 4xx and 5xx responses MAY also have a message body to
   carry additional response information.  Generally, a message body MAY
   be attached to any RTSP 2.0 request or response, but the content of
   the message body MAY be ignored by the receiver.  Extensions to this
   specification can specify the purpose and content of message bodies,
   including requiring their inclusion.

   In this section, both sender and recipient refer to either the client
   or the server, depending on who sends and who receives the message
   body.

9.1.  Message Body Header Fields

   Message body header fields define meta-information about the content
   data in the message body.  The message body header fields are listed
   in Table 6.

                   +------------------+----------------+
                   | Header           | Defined in     |
                   +------------------+----------------+
                   | Allow            | Section 18.6   |
                   |                  |                |
                   | Content-Base     | Section 18.14  |
                   |                  |                |
                   | Content-Encoding | Section 18.15  |
                   |                  |                |
                   | Content-Language | Section 18.16  |
                   |                  |                |
                   | Content-Length   | Section 18.17  |
                   |                  |                |
                   | Content-Location | Section 18.18  |
                   |                  |                |
                   | Content-Type     | Section 18.19  |
                   |                  |                |
                   | Expires          | Section 18.22  |
                   |                  |                |
                   | Last-Modified    | Section 18.27  |
                   +------------------+----------------+

                  Table 6: The RTSP Message Body Headers

Top      Up      ToC       Page 49 
   The extension-header mechanism allows additional message body header
   fields to be defined without changing the protocol, but these fields
   cannot be assumed to be recognizable by the recipient.  Unrecognized
   header fields MUST be ignored by the recipient and forwarded by
   proxies.

9.2.  Message Body

   An RTSP message with a message body MUST include the Content-Type and
   Content-Length headers.  When a message body is included with a
   message, the data type of that content data is determined via the
   Content-Type and Content-Encoding header fields.

   Content-Type specifies the media type of the underlying data.  There
   is no default media format and the actual format used in the body is
   required to be explicitly stated in the Content-Type header.  By
   being explicit and always requiring the inclusion of the Content-Type
   header with accurate information, one avoids the many pitfalls in a
   heuristic-based interpretation of the body content.  The user
   experience of HTTP and email have suffered from relying on such
   heuristics.

   Content-Encoding may be used to indicate any additional content-
   codings applied to the data, usually for the purpose of data
   compression, that are a property of the requested resource.  The
   default encoding is 'identity', i.e. no transformation of the message
   body.

   The Content-Length of a message is the length of the content,
   measured in octets.

9.3.  Message Body Format Negotiation

   The content format of the message body is provided using the Content-
   Type header (Section 18.19).  To enable the responder of a request to
   determine which media type it should use, the requester may include
   the Accept header (Section 18.1) in a request to identify supported
   media types or media type ranges suitable to the response.  In case
   the responder is not supporting any of the specified formats, then
   the request response will be a 406 (Not Acceptable) error code.

   The media types that may be used on requests with message bodies need
   to be determined through the use of feature tags, specification
   requirement, or trial and error.  Trial and error works because when
   the responder does not support the media type of the message body, it
   will respond with a 415 (Unsupported Media Type).

Top      Up      ToC       Page 50 
   The formats supported and their negotiation is done individually on a
   per method and direction (request or response body) direction.
   Requirements on supporting particular media types for use as message
   bodies in requests and response SHALL also be specified on a per-
   method and per-direction basis.

10.  Connections

   RTSP messages are transferred between RTSP agents and proxies using a
   transport connection.  This transport connection uses TCP or TCP/TLS.
   This transport connection is referred to as the "connection" or "RTSP
   connection" within this document.

   RTSP requests can be transmitted using the two different connection
   scenarios listed below:

   o  persistent - a transport connection is used for several request/
      response transactions;

   o  transient - a transport connection is used for each single
      request/response transaction.

   RFC 2326 attempted to specify an optional mechanism for transmitting
   RTSP messages in connectionless mode over a transport protocol such
   as UDP.  However, it was not specified in sufficient detail to allow
   for interoperable implementations.  In an attempt to reduce
   complexity and scope, and due to lack of interest, RTSP 2.0 does not
   attempt to define a mechanism for supporting RTSP over UDP or other
   connectionless transport protocols.  A side effect of this is that
   RTSP requests MUST NOT be sent to multicast groups since no
   connection can be established with a specific receiver in multicast
   environments.

   Certain RTSP headers, such as the CSeq header (Section 18.20), which
   may appear to be relevant only to connectionless transport scenarios,
   are still retained and MUST be implemented according to this
   specification.  In the case of CSeq, it is quite useful for matching
   responses to requests if the requests are pipelined (see Section 12).
   It is also useful in proxies for keeping track of the different
   requests when aggregating several client requests on a single TCP
   connection.

10.1.  Reliability and Acknowledgements

   Since RTSP messages are transmitted using reliable transport
   protocols, they MUST NOT be retransmitted at the RTSP level.
   Instead, the implementation must rely on the underlying transport to

Top      Up      ToC       Page 51 
   provide reliability.  The RTSP implementation may use any indication
   of reception acknowledgment of the message from the underlying
   transport protocols to optimize the RTSP behavior.

      If both the underlying reliable transport, such as TCP, and the
      RTSP application retransmit requests, each packet loss or message
      loss may result in two retransmissions.  The receiver typically
      cannot take advantage of the application-layer retransmission
      since the transport stack will not deliver the application-layer
      retransmission before the first attempt has reached the receiver.
      If the packet loss is caused by congestion, multiple
      retransmissions at different layers will exacerbate the
      congestion.

   Lack of acknowledgment of an RTSP request should be handled within
   the constraints of the connection timeout considerations described
   below (Section 10.4).

10.2.  Using Connections

   A TCP transport can be used for both persistent connections (for
   several message exchanges) and transient connections (for a single
   message exchange).  Implementations of this specification MUST
   support RTSP over TCP.  The scheme of the RTSP URI (Section 4.2)
   allows the client to specify the port it will contact the server on,
   and defines the default port to use if one is not explicitly given.

   In addition to the registered default ports, i.e., 554 (rtsp) and 322
   (rtsps), there is an alternative port 8554 registered.  This port may
   provide some benefits over non-registered ports if an RTSP server is
   unable to use the default ports.  The benefits may include
   preconfigured security policies as well as classifiers in network
   monitoring tools.

   An RTSP client opening a TCP connection to access a particular
   resource as identified by a URI uses the IP address and port derived
   from the host and port parts of the URI.  The IP address is either
   the explicit address provided in the URI or any of the addresses
   provided when performing A and AAAA record DNS lookups of the
   hostname in the URI.

   A server MUST handle both persistent and transient connections.

      Transient connections facilitate mechanisms for fault tolerance.
      They also allow for application-layer mobility.  A server-and-
      client pair that supports transient connections can survive the

Top      Up      ToC       Page 52 
      loss of a TCP connection; e.g., due to a NAT timeout.  When the
      client has discovered that the TCP connection has been lost, it
      can set up a new one when there is need to communicate again.

   A persistent connection is RECOMMENDED to be used for all
   transactions between the server and client, including messages for
   multiple RTSP sessions.  However, a persistent connection MAY be
   closed after a few message exchanges.  For example, a client may use
   a persistent connection for the initial SETUP and PLAY message
   exchanges in a session and then close the connection.  Later, when
   the client wishes to send a new request, such as a PAUSE for the
   session, a new connection would be opened.  This connection may be
   either transient or persistent.

   An RTSP agent MAY use one connection to handle multiple RTSP sessions
   on the same server.  The RTSP agent SHALL NOT use more than one
   connection per RTSP session at any given point.

      Having only one connection in use at any time avoids confusion
      regarding on which connection any server-to-client requests shall
      be sent.  Using a single connection for multiple RTSP sessions
      also saves complexity by enabling the server to maintain less
      state about its connection resources on the server.  Not using
      more than one connection at a time for a particular RTSP session
      avoids wasting connection resources and allows the server to track
      only the most recently used client-to-server connection for each
      RTSP session as being the currently valid server-to-client
      connection.

   RTSP allows a server to send requests to a client.  However, this can
   be supported only if a client establishes a persistent connection
   with the server.  In cases where a persistent connection does not
   exist between a server and its client, due to the lack of a signaling
   channel, the server may be forced to silently discard RTSP messages,
   and it may even drop an RTSP session without notifying the client.
   An example of such a case is when the server desires to send a
   REDIRECT request for an RTSP session to the client but is not able to
   do so because it cannot reach the client.  A server that attempts to
   send a request to a client that has no connection currently to the
   server SHALL discard the request.

      Without a persistent connection between the client and the server,
      the media server has no reliable way of reaching the client.
      Because of the likely failure of server-to-client established
      connections, the server will not even attempt establishing any
      connection.

Top      Up      ToC       Page 53 
      Queuing of server-to-client requests has been considered.
      However, a security issue exists as to how it might be possible to
      authorize a client establishing a new connection as being a
      legitimate receiver of a request related to a particular RTSP
      session, without the client first issuing requests related to the
      pending request.  Thus, it would be likely to make any such
      requests even more delayed and less useful.

   The sending of client and server requests can be asynchronous events.
   To avoid deadlock situations, both client and server MUST be able to
   send and receive requests simultaneously.  As an RTSP response may be
   queued up for transmission, reception or processing behind the peer
   RTSP agent's own requests, all RTSP agents are required to have a
   certain capability of handling outstanding messages.  A potential
   issue is that outstanding requests may time out despite being
   processed by the peer; this can be due to the response being caught
   in the queue behind a number of requests that the RTSP agent is
   processing but that take some time to complete.  To avoid this
   problem, an RTSP agent should buffer incoming messages locally so
   that any response messages can be processed immediately upon
   reception.  If responses are separated from requests and directly
   forwarded for processing, not only can the result be used
   immediately, the state associated with that outstanding request can
   also be released.  However, buffering a number of requests on the
   receiving RTSP agent consumes resources and enables a resource
   exhaustion attack on the agent.  Therefore, this buffer should be
   limited so that an unreasonable number of requests or total message
   size is not allowed to consume the receiving agent's resources.  In
   most APIs, having the receiving agent stop reading from the TCP
   socket will result in TCP's window being clamped, thus forcing the
   buffering onto the sending agent when the load is larger than
   expected.  However, as both RTSP message sizes and frequency may be
   changed in the future by protocol extensions, an agent should be
   careful about taking harsher measurements against a potential attack.
   When under attack, an RTSP agent can close TCP connections and
   release state associated with that TCP connection.

   To provide some guidance on what is reasonable, the following
   guidelines are given.  It is RECOMMENDED that:

   o  an RTSP agent should not have more than 10 outstanding requests
      per RTSP session;

   o  an RTSP agent should not have more than 10 outstanding requests
      that are not related to an RTSP session or that are requesting to
      create an RTSP session.

Top      Up      ToC       Page 54 
   In light of the above, it is RECOMMENDED that clients use persistent
   connections whenever possible.  A client that supports persistent
   connections MAY "pipeline" its requests (see Section 12).

   RTSP agents can send requests to multiple different destinations,
   either server or client contexts over the same connection to a proxy.
   Then, the proxy forks the message to the different destinations over
   proxy-to-agent connections.  In these cases when multiple requests
   are outstanding, the requesting agent MUST be ready to receive the
   responses out of order compared to the order they where sent on the
   connection.  The order between multiple messages for each destination
   will be maintained; however, the order between response from
   different destinations can be different.

      The reason for this is to avoid a head-of-line blocking situation.
      In a sequence of requests, an early outstanding request may take
      time to be processed at one destination.  Simultaneously, a
      response from any other destination that was later in the sequence
      of requests may have arrived at the proxy; thus, allowing out-of-
      order responses avoids forcing the proxy to buffer this response
      and instead deliver it as soon as possible.  Note, this will not
      affect the order in which the messages sent to each separate
      destination were processed at the request destination.

   This scenario can occur in two cases involving proxies.  The first is
   a client issuing requests for sessions on different servers using a
   common client-to-proxy connection.  The second is for server-to-
   client requests, like REDIRECT being sent by the server over a common
   transport connection the proxy created for its different connecting
   clients.

10.3.  Closing Connections

   The client MAY close a connection at any point when no outstanding
   request/response transactions exist for any RTSP session being
   managed through the connection.  The server, however, SHOULD NOT
   close a connection until all RTSP sessions being managed through the
   connection have been timed out (Section 18.49).  A server SHOULD NOT
   close a connection immediately after responding to a session-level
   TEARDOWN request for the last RTSP session being controlled through
   the connection.  Instead, the server should wait for a reasonable
   amount of time for the client to receive and act upon the TEARDOWN

Top      Up      ToC       Page 55 
   response and then initiate the connection closing.  The server SHOULD
   wait at least 10 seconds after sending the TEARDOWN response before
   closing the connection.

      This is to ensure that the client has time to issue a SETUP for a
      new session on the existing connection after having torn the last
      one down.  Ten seconds should give the client ample opportunity to
      get its message to the server.

   A server SHOULD NOT close the connection directly as a result of
   responding to a request with an error code.

      Certain error responses such as 460 (Only Aggregate Operation
      Allowed) (Section 17.4.24) are used for negotiating capabilities
      of a server with respect to content or other factors.  In such
      cases, it is inefficient for the server to close a connection on
      an error response.  Also, such behavior would prevent
      implementation of advanced or special types of requests or result
      in extra overhead for the client when testing for new features.
      On the other hand, keeping connections open after sending an error
      response poses a Denial-of-Service (DoS) security risk
      (Section 21).

   The server MAY close a connection if it receives an incomplete
   message and if the message is not completed within a reasonable
   amount of time.  It is RECOMMENDED that the server wait at least 10
   seconds for the completion of a message or for the next part of the
   message to arrive (which is an indication that the transport and the
   client are still alive).  Servers believing they are under attack or
   that are otherwise starved for resources during that event MAY
   consider using a shorter timeout.

   If a server closes a connection while the client is attempting to
   send a new request, the client will have to close its current
   connection, establish a new connection, and send its request over the
   new connection.

   An RTSP message SHOULD NOT be terminated by closing the connection.
   Such a message MAY be considered to be incomplete by the receiver and
   discarded.  An RTSP message is properly terminated as defined in
   Section 5.

Top      Up      ToC       Page 56 
10.4.  Timing Out Connections and RTSP Messages

   Receivers of a request (responders) SHOULD respond to requests in a
   timely manner even when a reliable transport such as TCP is used.
   Similarly, the sender of a request (requester) SHOULD wait for a
   sufficient time for a response before concluding that the responder
   will not be acting upon its request.

   A responder SHOULD respond to all requests within 5 seconds.  If the
   responder recognizes that the processing of a request will take
   longer than 5 seconds, it SHOULD send a 100 (Continue) response as
   soon as possible.  It SHOULD continue sending a 100 response every 5
   seconds thereafter until it is ready to send the final response to
   the requester.  After sending a 100 response, the responder MUST send
   a final response indicating the success or failure of the request.

   A requester SHOULD wait at least 10 seconds for a response before
   concluding that the responder will not be responding to its request.
   After receiving a 100 response, the requester SHOULD continue waiting
   for further responses.  If more than 10 seconds elapse without
   receiving any response, the requester MAY assume that the responder
   is unresponsive and abort the connection by closing the TCP
   connection.

   In some cases, multiple RTSP sessions share the same transport
   connection; abandoning a request and closing the connection may have
   significant impact on those other sessions.  First of all, other RTSP
   requests may have become queued up due to the request taking a long
   time to process.  Secondly, those sessions also lose the possibility
   to receive server-to-client requests.  To mitigate that situation,
   the RTSP client or server SHOULD establish a new connection and send
   any requests that are queued up or that haven't received a response
   on this new connection.  Thirdly, to ensure that the RTSP server
   knows which connection is valid for a particular RTSP session, the
   RTSP agent SHOULD send a keep-alive request, if no other request will
   be sent immediately for that RTSP session, for each RTSP session on
   the old connection.  The keep-alive request will normally be a
   SET_PARAMETER with a session header to inform the server that this
   agent cares about this RTSP session.

   A requester SHOULD wait longer than 10 seconds for a response if it
   is experiencing significant transport delays on its connection to the
   responder.  The requester is capable of determining the Round-Trip
   Time (RTT) of the request/response cycle using the Timestamp header
   (Section 18.53) in any RTSP request.

Top      Up      ToC       Page 57 
      The 10-second wait was chosen for the following reasons.  It gives
      TCP time to perform a couple of retransmissions, even if operating
      on default values.  It is short enough that users may not abandon
      the process themselves.  However, it should be noted that 10
      seconds can be aggressive on certain types of networks.  The
      5-second value for 1xx messages is half the timeout giving a
      reasonable chance of successful delivery before timeout happens on
      the requester side.

10.5.  Showing Liveness

   RTSP requires the client to periodically show its liveness to the
   server or the server may terminate any session state.  Several
   different protocol mechanism include in their usage a liveness proof
   from the client.  These mechanisms are RTSP requests with a Session
   header to the server; if RTP & RTCP is used for media data transport
   and the transport is established, the RTCP message proves liveness;
   or through any other used media-transport protocol capable of
   indicating liveness of the RTSP client.  It is RECOMMENDED that a
   client not wait to the last second of the timeout before trying to
   send a liveness message.  The RTSP message may take some time to
   arrive safely at the receiver, due to packet loss and TCP
   retransmissions.  To show liveness between RTSP requests being issued
   to accomplish other things, the following mechanisms can be used, in
   descending order of preference:

   RTCP: If RTP is used for media transport, RTCP SHOULD be used.  If
         RTCP is used to report transport statistics, it will
         necessarily also function as a keep-alive.  The server can
         determine the client by network address and port together with
         the fact that the client is reporting on the server's RTP
         sender sources (synchronization source (SSRCs)).  A downside of
         using RTCP is that it only gives statistical guarantees of
         reaching the server.  However, the probability of a false
         client timeout is so low that it can be ignored in most cases.
         For example, assume a session with a 60-second timeout and
         enough bitrate assigned to RTCP messages to send a message from
         client to server on average every 5 seconds.  That client has,
         for a network with 5% packet loss, a probability of failing to
         confirm liveness within the timeout interval for that session
         of 2.4*E-16.  Sessions with shorter timeouts, much higher
         packet loss, or small RTCP bandwidths SHOULD also implement one
         or more of the mechanisms below.

Top      Up      ToC       Page 58 
   SET_PARAMETER:  When using SET_PARAMETER for keep-alives, a body
         SHOULD NOT be included.  This method is the RECOMMENDED RTSP
         method to use for a request intended only to perform keep-
         alives.  RTSP servers MUST support the SET_PARAMETER method, so
         that clients can always use this mechanism.

   GET_PARAMETER:  When using GET_PARAMETER for keep-alives, a body
         SHOULD NOT be included, dependent on implementation support in
         the server.  Use the OPTIONS method to determine if there is
         method support or simply try.

   OPTIONS:  This method is also usable, but it causes the server to
         perform more unnecessary processing and results in bigger
         responses than necessary for the task.  The reason is that the
         server needs to determine the capabilities associated with the
         media resource to correctly populate the Public and Allow
         headers.

   The timeout parameter of the Session header (Section 18.49) MAY be
   included in a SETUP response and MUST NOT be included in requests.
   The server uses it to indicate to the client how long the server is
   prepared to wait between RTSP commands or other signs of life before
   closing the session due to lack of activity (see Appendix B).  The
   timeout is measured in seconds, with a default of 60 seconds.  The
   length of the session timeout MUST NOT be changed in an established
   session.

10.6.  Use of IPv6

   Explicit IPv6 [RFC2460] support was not present in RTSP 1.0.  RTSP
   2.0 has been updated for explicit IPv6 support.  Implementations of
   RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP
   headers.  Although the general URI format envisages potential future
   new versions of the literal IP address, usage of any such new version
   would require other modifications to the RTSP specification (e.g.,
   address fields in the Transport header (Section 18.54)).

10.7.  Overload Control

   Overload in RTSP can occur when servers and proxies have insufficient
   resources to complete the processing of a request.  An improper
   handling of such an overload situation at proxies and servers can
   impact the operation of the RTSP deployment, and probably worsen the
   situation.  RTSP defines the 503 (Service Unavailable) response
   (Section 17.5.4) to let servers and proxies notify requesting proxies
   and RTSP clients about an overload situation.  In conjunction with

Top      Up      ToC       Page 59 
   the Retry-After header (Section 18.44), the server or proxy can
   indicate the time after which the requesting entity can send another
   request to the proxy or server.

   There are two scopes of such 503 answers.  The first scope is for an
   established RTSP session, where the request resulting in the 503
   response as well as the response itself carries a Session header
   identifying the session that is suffering overload.  This response
   only applies to this particular session.  The other scope is the
   general RTSP server as identified by the host in the Request-URI.
   Such a 503 answer with any Retry-After header applies to all requests
   that are not session specific to that server, including a SETUP
   request intended to create a new RTSP session.

   Another scope for overload situations exists: the RTSP proxy.  To
   enable an RTSP proxy to signal that it is overloaded, or otherwise
   unavailable and unable to handle the request, a 553 response code has
   been defined with the meaning "Proxy Unavailable".  As with servers,
   there is a separation in response scopes between requests associated
   with existing RTSP sessions and requests to create new sessions or
   general proxy requests.

   Simply implementing and using the 503 (Service Unavailable) and 553
   (Proxy Unavailable) response codes is not sufficient for properly
   handling overload situations.  For instance, a simplistic approach
   would be to send the 503 response with a Retry-After header set to a
   fixed value.  However, this can cause a situation in which multiple
   RTSP clients again send requests to a proxy or server at roughly the
   same time, which may again cause an overload situation.  Another
   situation would be if the "old" overload situation is not yet
   resolved, i.e., the length indicated in the Retry-After header was
   too short for the overload situation to subside.

   An RTSP server or proxy in an overload situation must select the
   value of the Retry-After header carefully, bearing in mind its
   current load situation.  It is REQUIRED to increase the timeout
   period in proportion to the current load on the server, i.e., an
   increasing workload should result in an increased length of the
   indicated unavailability.  It is REQUIRED not to send the same value
   in the Retry-After header to all requesting proxies and clients, but
   to add a variation to the mean value of the Retry-After header.

   A more complex case may arise when a load-balancing RTSP proxy is in
   use.  This is the case when an RTSP proxy is used to select amongst a
   set of RTSP servers to handle the requests or when multiple server
   addresses are available for a given server name.  The proxy or client
   may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable)
   response code from one of its RTSP servers or proxies, or a TCP

Top      Up      ToC       Page 60 
   timeout (if the server is even unable to handle the request message).
   The proxy or client simply retries the other addresses or configured
   proxies, but it may also receive a 503 (Service Unavailable) or 553
   (Proxy Unavailable) response or TCP timeouts from those addresses.
   In such a situation, where none of the RTSP servers/proxies/addresses
   can handle the request, the RTSP agent has to wait before it can send
   any new requests to the RTSP server.  Any additional request to a
   specific address MUST be delayed according to the Retry-After headers
   received.  For addresses where no response was received or TCP
   timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
   That timer MUST be doubled for each additional failure to connect or
   receive response until the value exceeds 30 minutes when the timer's
   mean value may be set to 30 minutes.  It is REQUIRED not to set the
   same value in the timer for each scheduling, but instead to add a
   variation to the mean value, resulting in picking a random value
   within the range of 0.5 to 1.5 times the mean value.



(page 60 continued on part 4)

Next Section