100rel
MUST NOT be present in any requests excepting INVITE, although other extensions to SIP may allow its usage with other request methods. If the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel
. The UAC SHOULD include this in all INVITE requests. A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel
. The provisional response to be sent reliably is constructed by the UAS and MUST contain a Require header field containing the option tag 100rel
, and MUST include an RSeq header field. Retransmissions of the reliable provisional response cease when a matching PRACK is received by the UA core. PRACK is like any other request within a dialog, and is treated likewise. A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and RSeq-num in the RAck header field match, respectively, the method and sequence number from the CSeq and the sequence number from the RSeq of the reliable provisional response.
SIP applications are not required to understand the meaning of all registered response codes, though such understanding is obviously desirable. However, applications must understand the class of any status code, as indicated by the first digit and outlined above. Applications treat any unrecognized status code as being equivalent to the x00 status code of that class, with the exception that an unrecognized status code must not be cached. For example, if a client receives an unrecognized status code of 431, it can safely assume that there was something wrong with its request and treat the Response as if it had received a BAD_REQUEST(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 which will explain the unusual status.
This specification supports the response codes defined in RFC3261 and also the response code extensions for the event notification framework and PUBLISH, documented in RFC3265 and RFC3909, these are highlighted in italic. Class status codes (x00, i.e. 100) are are highlighted in bold.
Class | Code |
PROVISIONAL (1xx) | |
SUCCESS (2xx) | |
REDIRECTION (3xx) | |
CLIENT_ERROR (4xx) | |
SERVER_ERROR (5xx) | |
GLOBAL_ERROR (6xx) | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|