0112-0115

0115 Client Behavior2

Note that both the transaction corresponding to the original request

   and the CANCEL transaction will complete independently.  However, a

   UAC canceling a request cannot rely on receiving a 487 (Request

   Terminated) response for the original request, as an RFC 2543-

   compliant UAS will not generate such a response.  If there is no

   final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the

   original transaction cancelled and SHOULD destroy the client

   transaction handling the original request.

 

0114 Client Behavior

   A CANCEL request SHOULD NOT be sent to cancel a request other than

   INVITE.

 

      Since requests other than INVITE are responded to immediately,

      sending a CANCEL for a non-INVITE request would always create a

      race condition.

The following procedures are used to construct a CANCEL request.  The

   Request-URI, Call-ID, To, the numeric part of CSeq, and From header

   fields in the CANCEL request MUST be identical to those in the

   request being cancelled, including tags.  A CANCEL constructed by a

   client MUST have only a single Via header field value matching the

   top Via value in the request being cancelled.  Using the same values

   for these header fields allows the CANCEL to be matched with the

   request it cancels (Section 9.2 indicates how such matching occurs).

   However, the method part【注意】 of the CSeq header field MUST have a value

   of CANCEL.  This allows it to be identified and processed as a

   transaction in its own right (See Section 17).

 

   If the request being cancelled contains a Route header field, the

   CANCEL request MUST include that Route header field's values.

      This is needed so that stateless proxies are able to route CANCEL

      requests properly.

 

   The CANCEL request MUST NOT contain any Require or Proxy-Require

   header fields.

 

   Once the CANCEL is constructed, the client SHOULD check whether it

   has received any response (provisional or final) for the request

   being cancelled (herein referred to as the "original request").

   If no provisional response has been received, the CANCEL request MUST

   NOT be sent; rather, the client MUST wait for the arrival of a

   provisional response before sending the request.  If the original

   request has generated a final response, the CANCEL SHOULD NOT be

   sent, as it is an effective no-op, since CANCEL has no effect on

   requests that have already generated a final response.  When the

   client decides to send the CANCEL, it creates a client transaction

   for the CANCEL and passes it the CANCEL request along with the

   destination address, port, and transport.  The destination address,

   port, and transport for the CANCEL MUST be identical to those used to

   send the original request.

 

      If it was allowed to send the CANCEL before receiving a response

      for the previous request, the server could receive the CANCEL

      before the original request.

 

  

 

 

 

0113 Canceling a Request

 

   The previous section has discussed general UA behavior for generating

   requests and processing responses for requests of all methods.  In

   this section, we discuss a general purpose method, called CANCEL.

 

   The CANCEL request, as the name implies, is used to cancel a previous

   request sent by a client.  Specifically, it asks the UAS to cease

   processing the request and to generate an error response to that

   request.  CANCEL has no effect on a request to which a UAS has

   already given a final response.  Because of this, it is most useful

   to CANCEL requests to which it can take a server long time to

   respond.  For this reason, CANCEL is best for INVITE requests, which

   can take a long time to generate a response.  In that usage, a UAS

   that receives a CANCEL request for an INVITE, but has not yet sent a

   final response, would "stop ringing", and then respond to the INVITE

   with a specific error response (a 487).

 

   CANCEL requests can be constructed and sent by both proxies and user

   agent clients.  Section 15 discusses under what conditions a UAC

   would CANCEL an INVITE request, and Section 16.10 discusses proxy

   usage of CANCEL.

 

   A stateful proxy responds to a CANCEL, rather than simply forwarding

   a response it would receive from a downstream element.  For that

   reason, CANCEL is referred to as a "hop-by-hop" request, since it is

   responded to at each stateful proxy hop.

 

 

0112 Redirect Servers2

When a redirect server returns a 3xx response to a request, it

   populates the list of (one or more) alternative locations into the

   Contact header field.  An "expires" parameter to the Contact header

   field values may also be supplied to indicate the lifetime of the

   Contact data.

 

   The Contact header field contains URIs giving the new locations or

   user names to try, or may simply specify additional transport

   parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)

   response may also give the same location and username that was

   targeted by the initial request but specify additional transport

   parameters such as a different server or multicast address to try, or

   a change of SIP transport from UDP to TCP or vice versa.

 

   However, redirect servers MUST NOT redirect a request to a URI equal

   to the one in the Request-URI; instead, provided that the URI does

   not point to itself, the server MAY proxy the request to the

   destination URI, or MAY reject it with a 404.

 

      If a client is using an outbound proxy, and that proxy actually

      redirects requests, a potential arises for infinite redirection

      loops.

 

   Note that a Contact header field value MAY also refer to a different

   resource than the one originally called.  For example, a SIP call

   connected to PSTN gateway may need to deliver a special informational

   announcement such as "The number you have dialed has been changed."

 

   A Contact response header field can contain any suitable URI

   indicating where the called party can be reached, not limited to SIP

   URIs.  For example, it could contain URIs for phones, fax, or irc (if

   they were defined) or a mailto:  (RFC 2368 [32]) URL.  Section 26.4.4

   discusses implications and limitations of redirecting a SIPS URI to a

   non-SIPS URI.

 

   The "expires" parameter of a Contact header field value indicates how

   long the URI is valid.  The value of the parameter is a number

   indicating seconds.  If this parameter is not provided, the value of

   the Expires header field determines how long the URI is valid.

   Malformed values SHOULD be treated as equivalent to 3600.