\section{{\INVITE}, {\ACK} and {\CANCEL}}

\subsection{\INVITE}
\label{sec:INVITE}

The {\INVITE} method indicates that the user or service is being invited
to participate in a session.  The message body {\MAY} contain a
description of the session to which the callee is being invited.  For
two-party calls, the caller indicates the type of media it is able to
receive and possibly the media it is willing to send as well as their
parameters such as network destination.  A success response {\MUST}
indicate in its message body which media the callee wishes to receive
and {\MAY} indicate the media the callee is going to send.

\motivation{Not all session description formats have the ability to
indicate sending media.}

The caller {\MAY} choose to omit the request body (i.e., not send a
session description) or send a session description that does not list
any media types.  This indicates that the caller does not know its
desired media characteristics until the call has been accepted.  In this
case, the UAS {\SHOULD} still return a session description in its
informational (1xx) or success (2xx) response, containing those media
streams and codecs it supports.

If the {\INVITE} request did not contain a complete session description,
the caller {\MUST} include one in the {\ACK} request.  A UAC {\MUSTNOT}
send an updated session description in an {\ACK} request if it had
already sent a session description in the {\INVITE} request. 
If the UAC wishes to modify the session after the call setup has begun,
it {\MUST} initiate another {\INVITE} transaction after the current
one has completed. 

\motivation{Delaying the session description until the {\ACK} request is
useful for gateways from H.323v1 to SIP, where the H.323 media
characteristics are not known until the call is established.}

A server {\MAY} automatically respond to an invitation for a conference
the user is already participating in, identified either by the SIP
\header{Call-ID} or a globally unique identifier within the session
description, with a 200 (OK) response.

The behavior of UAS depend on whether they are Internet telephony
gateways to the PSTN. A UAS not acting as a gateway which receives an
{\INVITE} with a \header{Request-URI} that does not correspond to one of
its configured addresses, {\MUST} respond with 404 (Not Found). 

A UAS acting as a gateway translates the {\INVITE} request into a
telephony signaling message.  If the {\INVITE} has a \header{Call-ID}
value that matches a recent call, the UAS compares the
\header{Request-URI} with the \header{Request-URI} of the previous
{\INVITE} request for the same \header{Call-ID}.  If the
\header{Request-URI} contains additional digits in the ``\header{user}''
part, the UAS treats the {\INVITE} as adding additional digits to the
original dialed string. This is known as overlap dialing.

If the gateway knows that the telephone number is incomplete, it returns
a 484 (Address Incomplete) status response.

If a user agent receives an {\INVITE} request for an existing call leg
with a higher \header{CSeq} sequence number than any previous {\INVITE}
for the same \header{Call-ID}, it {\MUST} check any version identifiers
in the session description or, if there are no version identifiers, the
content of the session description to see if it has changed.  It {\MUST}
also inspect any other header fields for changes.  If there is a change,
the user agent {\MUST} update any internal state or information
generated as a result of that header.  If the session description has
changed, the user agent server {\MUST} adjust the session parameters
accordingly, possibly after asking the user for confirmation. 
(Versioning of the session description can be used to accommodate the
capabilities of new arrivals to a conference, add or delete media or
change from a unicast to a multicast conference.)

If an {\INVITE} request for an existing session fails, the session
description agreed upon in the last successful {\INVITE} transaction
remains in force.

A UAC {\MUSTNOT} issue another {\INVITE} request for the same call leg
before the previous {\INVITE} 
transaction has completed.  A UAS that receives an
{\INVITE} before it sent the final response to an {\INVITE} with a lower
\header{CSeq} number on the same call leg {\MUST} return a 400 (Bad
Request) response and 
{\MUST} include a \header{Retry-After} header field with a randomly
chosen value of between 0 and 10 seconds.

If a UA $A$ sends an {\INVITE} request to $B$ and receives an {\INVITE}
request from $B$ before it has received the response to its request from
$B$, $A$ {\MAY} return a 500 (Internal Server Error), which {\SHOULD}
include a \header{Retry-After} header field specifying when the request
should be resubmitted.

\motivation{In most cases, a UA can assume that the order of messages
received corresponds to the order they were sent. In rare circumstances,
the response from $B$ and the request from $B$ may be reordered on the
wire.

In addition, if $A$ or $B$ change multicast addresses, strict
transaction ordering is necessary so that both sides agree on the final
result.}

A UAC {\MUST} be prepared to receive media data according to the session
description as soon as it sends an {\INVITE} (or re-{\INVITE}) and can
start sending media data when it receives a provisional or final
response containing a session description. 

The initial {\INVITE} from the UAC {\SHOULD} contain the \header{Allow}
and \header{Supported} header fields, and {\MAY} contain the
\header{Accept} header field.  A 200 (OK) response to the initial
{\INVITE} for a call {\SHOULD} contain the \header{Allow} and
\header{Supported} header fields, and {\MAY} contain the \header{Accept}
header field. 

\motivation{Including these header fields allows the UAC to determine
the features and extensions supported by the UAS for the duration of the
call, without probing.}

This method {\MUST} be supported by SIP proxy, redirect and user agent
servers as well as clients.

\subsubsection{{\ACK}}
\label{sec:ACK}

The {\ACK} request confirms that the client has received a final
response to an {\INVITE} request.  ({\ACK} is used {\em only} with
{\INVITE} requests.) Treatment of {\ACK} for a 200 class response
differs significantly from that of a non-200 class response. 2xx
responses are acknowledged by client user agents, all other final
responses by the first stateful proxy or client user agent to receive
the response.  The \header{Via} is always initialized to the host that
originates the {\ACK} request, i.e., the client user agent after a 2xx
response or the first proxy or UAC to receive a non-2xx final
response. For a non-200 class response, the \header{Via} in the {\ACK}
that is constructed {\MUST} be the same as the request being
acknowledged. The {\ACK} for a 200 class response will contain
\header{Route} headers if
\header{Record-Route} headers were present in the response. An {\ACK}
for a non-200 class response never contains \header{Route} headers.
The {\ACK} request for a 200 class response is forwarded as the
corresponding {\INVITE} request, based on its \header{Request-URI} or
\header{Route} headers, and thus {\MAY} take a different path than the
original {\INVITE} request, and {\MAY} even cause a new transport
connection to be opened in order to send it. The \header{Request-URI}
for the {\ACK} is set to the top entry in the route set for a 200
class response (see Section \ref{sec:rr}). For a non-200 class
response, the \header{Request-URI} {\MUST} be the same as the
\header{Request-URI} in the request being acknowledged. 

The {\ACK} request does not generate responses for any
transport protocol.

The {\ACK} request for a 200 class response {\MAY} contain a message
body with the final session description to be used by the callee. See
Section~\ref{sec:INVITE} for further details on the relationship
between session descriptions in {\INVITE} and {\ACK} requests.

A proxy server receiving an {\ACK} request after having sent a 3xx, 4xx,
5xx, or 6xx response must make a determination about whether the {\ACK}
is for it, or for some user agent or proxy server further downstream. 
This determination is made by examining the tag in the \header{To}
field.  If the tag in the {\ACK} \header{To} header field matches the
tag in the \header{To} header field of the response, and the
\header{From}, \header{CSeq} and \header{Call-ID} header fields in the
response match those in the {\ACK}, the {\ACK} is meant for the proxy
server.  Otherwise, the {\ACK} {\SHOULD} be proxied downstream as any
other request. However, an {\ACK} not destined for
the proxy {\SHOULDNOT} be retransmitted.

\motivation{It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a request along a
single branch.  This can happen under various error conditions,
typically when a forking proxy transitions from stateful to stateless
before receiving all responses.  The various responses will all be
identical, except for the tag in the \header{To} field, which is
different for each one.  It can therefore be used as a means to
disambiguate them.}

This method {\MUST} be supported by SIP user agents.

\subsection{{\CANCEL}}
\label{sec:CANCEL}

The {\CANCEL} request cancels a pending request with the same
\header{Call-ID}, \header{To}, \header{From}, top \header{Via} header
and \header{Request-URI} and \header{CSeq} (sequence number only)
header field values, but does not affect a completed
request or existing calls.  (A request is considered completed if the
server has returned a final status response.) The UAC can use a {\BYE}
request to terminate a call if the {\CANCEL} arrived too late.

A user agent client or proxy client {\MAY} issue a {\CANCEL} request at
any time. A proxy client {\SHOULD} generate a {\CANCEL} request for branches
without a final response after it has forked a request and receives a
2xx or 6xx response from one of the branches. A UAC or proxy client
{\SHOULD} send a {\CANCEL} if the time noted in the \header{Expires} header
of the request has elapsed or no provisional or final response was
received after a client-determined timeout interval.  Finally, internal
logic such as scripts, {\MAY} trigger {\CANCEL} requests.

A stateful proxy that receives a {\CANCEL} request immediately
responds with a 200 class response. It then generates a new {\CANCEL},
and forwards the request to all destinations with pending requests. A
stateless proxy, or a stateful proxy with no transaction state for the
cancelled request, proxies the {\CANCEL} request to the same set of
destinations the original request was proxied to.

The \header{Request-URI}, topmost \header{Via}, \header{Call-ID},
\header{To}, the numeric part of \header{CSeq} and \header{From}
header fields in the {\CANCEL} request are identical to those in the
original request being cancelled, including tags.  This allows a
{\CANCEL} request to be matched with the request it cancels.  However,
to allow the client to distinguish responses to the {\CANCEL} from
those to the original request, the
\header{CSeq} \header{Method} component is set to \header{CANCEL}.
The \header{Via} header field is initialized to the proxy issuing the
{\CANCEL} request.  (Thus, responses to this {\CANCEL} request only
reach the issuing proxy.)

The behavior of the user agent or redirect server on receiving a
{\CANCEL} request depends on whether the server has already sent a
final response for the original request.  If it has, the {\CANCEL}
request has no effect on the original request, any call state and on
the responses generated for the original request.  If the server has
not issued a final response for the original request, it immediately
responds to the original request with a 487 (Request Terminated),
following normal rules for response retransmissions defined in Section
\ref{sec:transport}.  For {\INVITE}
requests, the UAC as usual sends an {\ACK} request to confirm receipt
of any final response.  The {\CANCEL} request itself is answered with
a 200 (OK) response in either case. If the UAS or
redirect server has no record of the request being cancelled, the
{\CANCEL} is responded to with a 481.

A proxy client or UAC cannot rely on receiving a 487 (Request
Terminated) response, as a RFC 2543-compliant UAS will not generate such
a response.  If there has been no final response after 32 seconds, the
client {\MAY} consider the original transaction to have been cancelled.

\motivation{The {\BYE} request cannot be used to cancel branches of a
parallel search, since several branches may, through intermediate
proxies, find the same user agent server and then terminate the call. 
To terminate a call instead of just pending searches, the UAC must use
{\BYE} instead of or in addition to {\CANCEL}.  While {\CANCEL} can
terminate any pending request other than {\ACK} or {\CANCEL}, it is
typically useful only for {\INVITE}.  200 responses to {\INVITE} and 200
responses to {\CANCEL} can be distinguished by the method in the
\header{Cseq} header field.}

This method {\MUST} be supported by proxy servers and {\SHOULD} be
supported by all other SIP server types.
