21.2 Successful 2xx

   The request was successful.

21.2.1 200 OK

   The request has succeeded.  The information returned with the
   response depends on the method used in the request.

21.3 Redirection 3xx

   3xx responses give information about the user's new location, or
   about alternative services that might be able to satisfy the call.

21.3.1 300 Multiple Choices

   The address in the request resolved to several choices, each with its
   own specific location, and the user (or UA) can select a preferred
   communication end point and redirect its request to that location.

   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 (Section 20.10).
   Unlike HTTP, the SIP response MAY contain several Contact fields or a
   list of addresses in a Contact field.  UAs 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.

21.3.2 301 Moved Permanently

   The user can no longer be found at the address in the Request-URI,
   and the requesting client SHOULD retry at the new address given by
   the Contact header field (Section 20.10).  The requestor SHOULD
   update any local directories, address books, and user location caches
   with this new value and redirect future requests to the address(es)
   listed.

21.3.3 302 Moved Temporarily

   The requesting client SHOULD retry the request at the new address(es)
   given by the Contact header field (Section 20.10).  The Request-URI
   of the new request uses the value of the Contact header field in the
   response.

   The duration of the validity of the Contact URI can be indicated
   through an Expires (Section 20.19) header field or an expires
   parameter in the Contact header field.  Both proxies and UAs 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.

<< Prev - Next >>