9. 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.

9.1. 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.

   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(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop)-
   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.

9.2. Server Behavior

   The CANCEL method requests that the TU at the server side cancel a
   pending transaction.  The TU determines the transaction to be
   cancelled by taking the CANCEL request, and then assuming that the
   request method is anything but CANCEL or ACK and applying the
   transaction matching procedures of Section 17.2.3.  The matching
   transaction is the one to be cancelled.

   The processing of a CANCEL request at a server depends on the type of
   server.  A stateless proxy will forward it, a stateful proxy might
   respond to it and generate some CANCEL requests of its own, and a UAS
   will respond to it.  See Section 16.10 for proxy treatment of CANCEL.

   A UAS first processes the CANCEL request according to the general UAS
   processing described in Section 8.2.  However, since CANCEL requests
   are hop-by-hop and cannot be resubmitted, they cannot be challenged
   by the server in order to get proper credentials in an Authorization
   header field.  Note also that CANCEL requests do not contain a
   Require header field.

   If the UAS did not find a matching transaction for the CANCEL
   according to the procedure above, it SHOULD respond to the CANCEL
   with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction
   for the original request still exists, the behavior of the UAS on
   receiving a CANCEL request depends on whether it has already sent a
   final response for the original request.  If it has, the CANCEL
   request has no effect on the processing of the original request, no
   effect on any session state, and no effect on the responses generated
   for the original request.  If the UAS has not issued a final response
   for the original request, its behavior depends on the method of the
   original request.  If the original request was an INVITE, the UAS
   SHOULD immediately respond to the INVITE with a 487 (Request
   Terminated).  A CANCEL request has no impact on the processing of
   transactions with any other method defined in this specification.

   Regardless of the method of the original request, as long as the
   CANCEL matched an existing transaction, the UAS answers the CANCEL
   request itself with a 200 (OK) response.  This response is
   constructed following the procedures described in Section 8.2.6
   noting that the To tag of the response to the CANCEL and the To tag
   in the response to the original request SHOULD be the same.  The
   response to CANCEL is passed to the server transaction for
   transmission.