\section{Initiating a Session}
\label{sec:initiate}

\subsection{Overview}
\label{sec:initiateoverview}

When a user agent client desires to initiate a session (for example,
audio, video, or a game), it formulates an {\INVITE} request.  The
{\INVITE} request asks a server to establish a session.  This request may be 
forwarded by proxies, eventually arriving at one or more UAS that can
potentially accept the invitation.  These UASs will frequently need to
query the user about whether to accept the invitation.  After some time,
those UAS can accept the invitation (meaning the session is to be
established) by sending a 2xx response.  If the invitation is not
accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the
reason for the rejection.   Before sending a final
response, the UAS can also send provisional responses (1xx) to advise
the UAC of progress in contacting the called user.  

After possibly receiving one or more provisional responses, the UAC will
get one or more 2xx responses or one non-2xx final response.  Because of
the protracted amount of time it can take to receive final responses to
{\INVITE}, the reliability mechanisms for {\INVITE} transactions differ
from those of other requests (like {\OPTIONS}).  Once it receives a
final response, the UAC needs to send an {\ACK} for every final response
it receives.  The procedure for sending this {\ACK} depends on the type
of response.  For final responses between 300 and 699, the {\ACK}
processing is done in the transaction layer and follows one set of rules
(See Section~\ref{sec:transactions}).  For 2xx responses, the {\ACK} is
generated by the UAC core. 

A 2xx response to an {\INVITE} establishes a session, and it also
creates a dialog between the UA that issued the {\INVITE} and the UA
that generated the 2xx response.  Therefore, when multiple 2xx responses
are received from different remote UAs (because the {\INVITE} forked),
each 2xx establishes a different dialog.  All these dialogs are part of
the same call. 

\begin{changebar}
This section provides details on the establishment of a session using
{\INVITE}. A UA that supports {\INVITE} {\MUST} also support {\ACK}, {\CANCEL} and {\BYE}. 
\end{changebar}

\subsection{UAC Processing}
\label{sec:initiatecaller}

\subsubsection{Creating the Initial {\INVITE}}
\label{sec:initiateuac}

Since the initial {\INVITE} represents a request outside of a dialog,
its construction follows the procedures of 
Section~\ref{sec:general:gen}.  Additional processing is required for the
specific case of {\INVITE}.

An \header{Allow} header field (Section~\ref{sec:Allow}) {\SHOULD} be
present in the {\INVITE}.  It indicates what methods can be invoked
within a dialog, on the UA sending the {\INVITE}, for the duration of
the dialog.  For example, a UA capable of receiving {\INFO} requests
within a dialog~\citenonnorm{rfc2976} {\SHOULD} include an \header{Allow}
header field listing the {\INFO} method.

A \header{Supported} header field (Section~\ref{sec:Supported})
{\SHOULD} be present in the {\INVITE}.  It enumerates all the extensions
understood by the UAC. 

An \header{Accept} (Section~\ref{sec:Accept}) header field {\MAY} be
present in the {\INVITE}.  It indicates which Content-Types are
acceptable to the UA, in both the response received by it, and in any
subsequent requests sent to it within dialogs established by the
{\INVITE}.  The \header{Accept} header field is especially useful for
indicating support of various session description formats.

The UAC {\MAY} add an \header{Expires} header field 
(Section~\ref{sec:Expires}) to limit the validity of the invitation.  If the
time indicated in the \header{Expires} header field is reached and no
final answer for the {\INVITE} has been received the UAC core {\SHOULD}
generate a {\CANCEL} request for the {\INVITE}, as per 
Section~\ref{sec:canceling}.

A UAC {\MAY} also find it useful to add, among others, \header{Subject}
(Section~\ref{sec:Subject}), \header{Organization} 
(Section~\ref{sec:Organization}) and \header{User-Agent} 
(Section~\ref{sec:User-Agent}) header fields.  They all contain information
related to the {\INVITE}.

The UAC {\MAY} choose to add a message body to the {\INVITE}. 
Section~\ref{sec:general:uac:steps} deals with how to construct the
header fields -- \header{Content-Type} among others -- needed to
describe the message body.


There are special rules for message bodies that contain a session
description - their corresponding \header{Content-Disposition} is
``session''.  SIP uses an offer/answer model where one UA sends a
session description, called the offer, which contains a proposed
description of the session.  The offer indicates the desired
communications means (audio, video, games), parameters of those means
(such as codec types) and addresses for receiving media from the
answerer.  The other UA responds with another session description,
called the answer, which indicates which communications means are
accepted, the parameters that apply to those means, and addresses for
receiving media from the offerer.  The offer/answer model defines
restrictions on when offers and answers can be made. This results in
restrictions on where the offers and answers can appear in SIP
messages. \begin{changebar}In this specification, offers and answers can only appear in
{\INVITE} requests and responses, and {\ACK}. \end{changebar} The usage of offers and
answers is further restricted. For the initial {\INVITE} transaction,
the rules are:

\begin{itemize}
\item The initial offer {\MUST} be in either an {\INVITE} or, if not
there, in the first reliable non-failure message from the UAS back to the
UAC. \begin{changebar} In this specification, that is the final 2xx
response. \end{changebar}


\item If the initial offer is in an {\INVITE}, the answer {\MUST} be
in a reliable non-failure message from UAS back to UAC which is correlated
to that {\INVITE}. \begin{changebar} For this
specification, that is only the final 2xx response to that
{\INVITE}. \end{changebar}

\item If the initial offer is in the first reliable non-failure message from the
UAS back to UAC, the answer {\MUST} be in the acknowledgement
for that message \begin{changebar} (in this specification, {\ACK} for
a 2xx response).\end{changebar}

\item After having sent or received an answer to the first offer, the
UAC {\MAY} generate subsequent offers in requests, but only if it has
received answers to any previous offers, and has not sent any offers
to which it hasn't gotten an answer.

\begin{changebar}
\item Once the UAS has sent or received an answer to the initial 
offer, it {\MUSTNOT} generate subsequent offers in any responses to
the initial {\INVITE}. This means that a UAS
based on this specification alone can never generate subsequent
offers until completion of the initial transaction.
\end{changebar}
\end{itemize}

\begin{changebar}
Concretely, the above rules specify two exchanges - the offer is in the
{\INVITE}, and the answer in the 2xx, or the offer is in the 2xx, and
the answer is in the {\ACK}. All user agents that support {\INVITE}
{\MUST} support these two exchanges. 
\end{changebar}

The Session Description Protocol (SDP) (RFC~2327~\citenorm{rfc2327})
{\MUST} be supported by all user agents as a means to describe sessions,
and its usage for constructing offers and answers {\MUST} follow the
procedures defined in~\citenorm{draft-ietf-mmusic-sdp-offer-answer}.

The restrictions of the offer-answer model just described only
apply to bodies whose \header{Content-Disposition} header field value is
``session''.  Therefore, it is possible that both the {\INVITE} and the
{\ACK} contain a body message (for example, the {\INVITE} carries a photo
(\header{Content-Disposition}:  render) and the {\ACK} a session
description (\header{Content-Disposition}:  session)).  \motivation{If
the \header{Content-Disposition} header field is missing, bodies of
\header{Content-Type} \texttt{application/sdp} imply the disposition
``session'', while other content types imply ``render''.}

Once the {\INVITE} has been created, the UAC follows the procedures
defined for sending requests outside of a dialog (Section~\ref{sec:ua}). 
This results in the construction of a client transaction that will
ultimately send the request and deliver responses to the UAC. 

\subsubsection{Processing {\INVITE} Responses}
\label{sec:initiateresponses}

Once the {\INVITE} has been passed to the {\INVITE} client transaction,
the UAC waits for responses for the {\INVITE}. If the {\INVITE} client
transaction returns a timeout rather than a response the TU acts as if a
408 (Request Timeout) response had been received, as described in Section~\ref{sec:general:resp-proc}.  

\paragraph{\header{1xx responses}}

Zero, one or multiple provisional responses may arrive before one or
more final responses are received.  Provisional responses for an
{\INVITE} request can create ``early dialogs''.  If a provisional
response has a tag in the \header{To} field, and if the dialog ID of the
response does not match an existing dialog, one is constructed using the
procedures defined in Section~\ref{sec:dialog:construct:uac}.

\begin{changebar}
The early dialog will only be needed if the UAC needs to send a request
to its peer within the dialog before the initial {\INVITE} transaction
completes. Header fields present in a provisional response are
applicable as long as the dialog is in the early state (for example, an
\header{Allow} header field in a provisional response contains the
methods that can be used in the dialog while this is in the early
state).
\end{changebar}

\paragraph{\header{3xx responses}} A 3xx response may contain one or more 
\header{Contact} header field values providing new addresses where the callee
might be reachable.  Depending on the status code of the 3xx response
(see Section~\ref{sec:response-codes:3xx}) the UAC {\MAY} choose to try
those new addresses.

\paragraph{\header{4xx, 5xx and 6xx responses}} A single non-2xx final
response may be received for the {\INVITE}.  4xx, 5xx and 6xx responses
may contain a \header{Contact} header field value indicating the location
where additional information about the error can be found.

All early dialogs are considered terminated upon reception of the
non-2xx final response.

After having received the non-2xx final response the UAC core considers
the {INVITE} transaction completed.  The {\INVITE} client transaction
handles generation of {\ACK}s for the response 
(see Section~\ref{sec:transactions}).

\paragraph{\header{2xx responses}}
\label{sec:initiateresponses:2xx}

Multiple 2xx responses may arrive at
the UAC for a single {\INVITE} request due to a forking proxy.  Each
response is distinguished by the \header{tag} parameter in the
\header{To} header field, and each represents a distinct dialog, with a
distinct dialog identifier. 

\begin{changebar}
If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog {\MUST} be transitioned to
the ``confirmed'' state, and the route set for the dialog {\MUST} be
recomputed based on the 2xx response using the procedures of 
Section~\ref{sec:dialog:uac:response}. Otherwise, a new dialog in the 
``confirmed'' state {\MUST} be constructed using the procedures of 
Section~\ref{sec:dialog:construct:uac}.
\motivation{ Note that the only piece of state that is recomputed is 
the route set. Other pieces of state such as the highest sequence numbers 
(remote and local) sent within the dialog are not recomputed. 
The route set only is recomputed for backwards compatibility.  
RFC~2543 did not mandate mirroring of the
\header{Record-Route} header field in a 1xx, only 2xx.  However, we cannot
update the entire state of the dialog, since mid-dialog requests may have 
been sent within the early dialog, modifying the sequence numbers, for example.}
\end{changebar}

The UAC core {\MUST} generate an {\ACK} request for each 2xx received
from the transaction layer.  The header fields of the {\ACK} are
constructed in the same way as for any request sent within a dialog (see
Section~\ref{sec:dialog}) with the exception of the \header{CSeq} and
the header fields related to authentication.  The sequence number of the
\header{CSeq} header field {\MUST} be the same as the {\INVITE} being
acknowledged, but the \header{CSeq} method {\MUST} be {\ACK}.  The
{\ACK} {\MUST} contain the same credentials as the {\INVITE}.
 If the
2xx contains an offer (based on the rules above), 
the {\ACK} {\MUST} carry an answer in its body.   If the offer
in the 2xx response is not acceptable, the UAC core {\MUST} generate a
valid answer in the {\ACK} and then send a {\BYE} immediately.

Once the {\ACK} has been constructed, the procedures
of~\citenorm{draft-ietf-sip-srv} are used to determine the destination address,
port and transport.   However, the request is passed to
the transport layer directly for transmission, rather than a client
transaction.  This is because the UAC core handles retransmissions of
the {\ACK}, not the transaction layer.  The {\ACK} {\MUST} be passed to
the client transport every time a retransmission of the 2xx final
response that triggered the {\ACK} arrives.

The UAC core considers the {\INVITE} transaction completed 64*T1 seconds
after the reception of the first 2xx response.  At this point all the
early dialogs that have not transitioned to established dialogs are
terminated.  Once the {\INVITE} transaction is considered completed by
the UAC core, no more new 2xx responses are expected to arrive.

If, after acknowledging any 2xx response to an {\INVITE}, the UAC
does not want to continue with that dialog, then the UAC {\MUST}
terminate the dialog by sending a {\BYE} request as described 
in Section~\ref{sec:terminate}.

\subsection{UAS Processing}
\label{sec:initiatecallee}

\subsubsection{Processing of the {\INVITE}}
\label{sec:initiateuas}

The UAS core will receive {\INVITE} requests from the transaction layer. 
It first performs the request processing procedures of 
Section~\ref{sec:general:req-process}, which are applied for both requests
inside and outside of a dialog. 

Assuming these processing states complete without generating a response,
the UAS core performs the additional processing steps:

\begin{enumerate}
\begin{changebar}
\item If the request is an {\INVITE} that contains an \header{Expires}
header field the UAS core 
sets a timer for the number of seconds indicated in the header field value. 
When the timer fires, the invitation is considered to be expired. If the
invitation expires before the UAS has
generated a final response, a 487 (Request Terminated) response {\SHOULD}
be generated.
\end{changebar}

\item If the request is a mid-dialog request, the method-independent
processing described in Section~\ref{sec:midcalluas} is first applied. 
It might also modify the session; Section~\ref{sec:modify} provides
details.

\item If the request has a tag in the \header{To} header field but the
dialog identifier does not match any of the existing dialogs, the UAS
may have crashed and restarted, or may have received a request for a
different (possibly failed) UAS.  Section~\ref{sec:midcalluas} provides
guidelines to achieve a robust behavior under such a situation.

\end{enumerate}

Processing from here forward assumes that the {\INVITE} is outside of a
dialog, and is thus for the purposes of establishing a new session.


The {\INVITE} may contain a session description, in which case the UAS
is being presented with an offer for that session.  It is possible that
the user is already a participant in that session, even though the
{\INVITE} is outside of a dialog.  This can happen when a user is
invited to the same multicast conference by multiple other participants. 
If desired, the UAS {\MAY} use identifiers within the session
description to detect this duplication.  For example, SDP contains a
session id and version number in the origin (\header{o}) field.  If the
user is already a member of the session, and the session parameters
contained in the session description have not changed, the UAS {\MAY}
silently accept the {\INVITE} (that is, send a 2xx response without
prompting the user).

If the {\INVITE} does not contain a session description, the UAS is being asked to participate in a session, and the UAC has
asked that the UAS provide the offer of the session. 
\begin{changebar}It {\MUST} provide the offer in its first non-failure reliable message
back to the UAC. In this specification, that is a 2xx response to the
{\INVITE}. \end{changebar}

The UAS can indicate progress, accept, redirect, or reject the
invitation.  In all of these cases, it formulates a response using the
procedures described in Section~\ref{sec:general:serv-resp}.

\paragraph{Progress}

If the UAS is not able to answer the invitation immediately, it can
choose to indicate some kind of progress to the UAC (for example, an
indication that a phone is ringing).  This is accomplished with a
provisional response between 101 and 199.  These provisional responses
establish early dialogs and therefore follow the procedures 
of Section~\ref{sec:dialog:construct:uas} in addition to those of 
Section~\ref{sec:general:serv-resp}. A UAS {\MAY} send as many provisional
responses as it likes.  Each of these {\MUST} indicate the same dialog
ID.  \begin{changebar} However, these will not be delivered
reliably. \end{changebar}

If the UAS desires an extended period of time to answer the
{\INVITE}, it will need to ask for an ``extension'' in order to
prevent proxies from canceling the transaction. A proxy has the
option of canceling a transaction when there is a gap of 3 minutes
between messages in a transaction. \begin{changebar} To prevent cancellation, the UAS
{\MUST} send a non-100 provisional response at every minute, to handle
the possibility of lost provisional responses. \end{changebar}

\motivation{An {\INVITE} transaction can go on for extended durations
when the user is placed on hold, or when interworking with PSTN
systems which allow communications to take place without answering the
call. The latter is common in Interactive Voice Response (IVR)
systems.} 

\paragraph{\header{The {\INVITE} is redirected}} If the UAS decides to
redirect the call, a 3xx response is sent.  A 300 (Multiple Choices),
301 (Moved Permanently) or 302 (Moved Temporarily) response {\SHOULD}
contain a \header{Contact} header field containing one or more URIs of new addresses
to be tried.  The response is passed to the {\INVITE} server
transaction, which will deal with its retransmissions.

\paragraph{\header{The {\INVITE} is rejected}} A common scenario occurs
when the callee is currently not willing or able to take additional
calls at this end system.  A 486 (Busy Here) {\SHOULD} be returned in
such scenario.  If the UAS knows that no other end system will be able
to accept this call a 600 (Busy Everywhere) response {\SHOULD} be sent
instead.  However, it is unlikely that a UAS will be able to know this
in general, and thus this response will not usually be used.  The
response is passed to the {\INVITE} server transaction, which will deal
with its retransmissions.


A UAS rejecting an offer contained in an {\INVITE} {\SHOULD} return a
488 (Not Acceptable Here) response.  Such a response {\SHOULD} include a
\header{Warning} header field value explaining why the offer was rejected.


\paragraph{\header{The {\INVITE} is accepted}}
\label{sec:initiateuas:accept}

The UAS core generates a
2xx response.  This response establishes a dialog, and therefore follows
the procedures of Section~\ref{sec:dialog:construct:uas} in addition to
those of Section~\ref{sec:general:serv-resp}.

A 2xx response to an {\INVITE} {\SHOULD} contain the \header{Allow}
header field and the \header{Supported} header field, and {\MAY} contain
the \header{Accept} header field.  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.


If the {\INVITE} request contained an offer, and the UAS had not yet
sent an answer, the 2xx {\MUST} contain an
answer.  If the {\INVITE} did not contain an offer, the 2xx {\MUST}
contain an offer if the UAS had not yet sent an offer. 


Once the response has been constructed it is passed to the {\INVITE}
server transaction. Note, however, that the {\INVITE}
server transaction will be destroyed as soon as it receives this final
response and passes it to the transport.  Therefore, it is necessary to pass periodically the response directly to the transport until the {\ACK} arrives.  The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are
defined in Section~\ref{sec:transactions}). Response retransmissions cease when an {\ACK} request for the response is received. This is independent of whatever transport protocols are used to send the response.

\motivation{Since 2xx is retransmitted end-to-end, there may be hops
between UAS and UAC that are UDP.  To ensure reliable delivery across
these hops, the response is retransmitted periodically even if the
transport at the UAS is reliable.}

\begin{changebar}
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an {\ACK}, the dialog is confirmed, but the session
{\SHOULD} be terminated. This is accomplished with a {\BYE} as described in
Section~\ref{sec:terminate}.
\end{changebar}

