Java Doc for Response.java in  » 6.0-JDK-Modules » Java-Advanced-Imaging » javax » sip » message » Java Source Code / Java DocumentationJava Source Code and Java Documentation

The Status-Code is a 3-digit integer result code that indicates the outcome 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, whereas the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.

RFC3261 defines status codes in the following classes:

• 1xx: Provisional -- request received, continuing to process the request; Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response.
  • This specification also supports the delivery of reliable provisional responses as defined in RFC 3262. When the UAC creates a new request, it can insist on reliable delivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 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.

• 2xx: Success -- the action was successfully received, understood, and accepted.
• 3xx: Redirection -- further action needs to be taken in order to complete the request; 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call.
• 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification. However, the same request to a different server might be successful.
• 5xx: Server Error -- the server failed to fulfill an apparently valid request; 5xx responses are failure responses given when a server itself has erred.
• 6xx: Global Failure -- the request cannot be fulfilled at any server; 6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.

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.

The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field.

A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client.

The duration of the validity of the Contact URI can be indicated through an Expires header field or an expires parameter in the Contact header field. Both proxies and User Agents MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions.

If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available.

The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body.

The choices SHOULD also be listed as Contact fields. Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. User Agents MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection.

This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.

Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).

A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.

It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response.

This status response is returned only if the client knows that no other end point will answer the request. This specification renames this status code from NOT_ACCEPTABLE as in RFC3261 to SESSION_NOT_ACCEPTABLE due to it conflict with 406 (Not Acceptable) defined in this interface.

This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user.