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.
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. 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.
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. 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. 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. Table 1:
+--------------------+----------------+ | 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
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.
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.
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
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.
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. Table 4. 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)
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 | | | | |
| 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 | | | | |
| 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
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. Section 5.3).
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. 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
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. 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).
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. 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.
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). 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
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.
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.
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. 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
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.
Section 18.53) in any RTSP request.
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.
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. 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)). Section 17.5.4) to let servers and proxies notify requesting proxies and RTSP clients about an overload situation. In conjunction with
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
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.