\section{Canceling a Request}
\label{sec:canceling}

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~\ref{sec:terminate} discusses under what conditions a UAC would
{\CANCEL} an {\INVITE} request, and 
Section~\ref{sec:proxy-cancel-processing} 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.

\subsection{Client Behavior}
\label{sec:canceluac}

A {\CANCEL} request {\SHOULDNOT} be sent to cancel a request other than
{\INVITE}.  \motivation{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
\header{Request-URI}, \header{Call-ID}, \header{To}, the numeric part of
\header{CSeq}, and \header{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
\header{Via} header field value matching the top \header{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~\ref{sec:canceluas} indicates how such matching occurs).  However, the
method part of the \header{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~\ref{sec:transactions}).

If the request being cancelled contains a \header{Route} header field,
the {\CANCEL} request {\MUST} include that \header{Route} header
field's values.  \motivation{This is needed so that stateless proxies are able
to route {\CANCEL} requests properly.}

The {\CANCEL} request {\MUSTNOT} contain any \header{Require} or
\header{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 {\MUSTNOT} 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} {\SHOULDNOT} 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.

\motivation{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-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~\ref{sec:transactions:client:invite:overview}), the client {\SHOULD}
then consider the original transaction cancelled and {\SHOULD} destroy
the client transaction handling the original request.

\subsection{Server Behavior}
\label{sec:canceluas}

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} and applying the transaction matching procedures
of Section~\ref{sec:transactions:server:match}.  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~\ref{sec:proxy-cancel-processing} for
proxy treatment of {\CANCEL}.

A UAS first processes the {\CANCEL} request according to the general UAS
processing described in Section~\ref{sec:general:req-process}.  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 \header{Authorization} header field.  Note also that {\CANCEL}
requests do not contain a \header{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).  The behavior
upon reception of a {\CANCEL} request for any other method defined in
this specification is effectively no-op.  

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~\ref{sec:general:serv-resp} noting that the \header{To} tag of
the response to the {\CANCEL} and the \header{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. 
