Knowlegde Through Fun Welcome To Mady's Site.

RTSP defines additional status codes and does not define some HTTP codes. After receiving and interpreting a request message, the recipient responds with an RTSP response message.
Response = Status-Line
*( general-header
| response-header
| entity-header )
CRLF
[ message-body ]
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.
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF

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.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 5 values for the first digit:
* 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood,
and accepted
* 3xx: Redirection - Further action must be taken in order to
complete the request
* 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/1.0, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended
- they may be replaced by local equivalents without affecting the
protocol. RTSP adopts most HTTP/1.1 status codes and
adds RTSP-specific status codes starting at x50 to avoid conflicts
with newly defined HTTP 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 the exception that an unrecognized response 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 entity returned with the response.
Response Header Fields
The response-header fields allow the request recipient to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
Response-header = Location
| Proxy-Authenticate
| Public
| Retry-After
| Server
| Vary
| WWW-Authenticate
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response- header fields if all parties in the communication recognize them to be response-header fields. Unrecognized header fields are treated as entity-header fields.