\section{Dialogs}
\label{sec:dialog}

A key concept for a user agent is that of a dialog.  A dialog represents
a peer-to-peer SIP relationship between two user agents that persists
for some time.  The dialog facilitates sequencing of messages between
the user agents and proper routing of requests between both of them. 
The dialog represents a context in which to interpret SIP messages. 
Section~\ref{sec:ua} discussed method independent UA processing for
requests and responses outside of a dialog.  This section discusses how
those requests and responses are used to construct a dialog, and then
how subsequent requests and responses are sent within a dialog.

\begin{changebar}
A dialog is identified at each UA with a dialog ID, which consists of
a
\header{Call-ID} value, a local tag and a remote tag.  The dialog ID
at each UA involved in the dialog is not
the same.  Specifically, the local tag at one UA is identical to the
remote tag at the peer UA.  The tags are opaque tokens that facilitate
the generation of unique dialog IDs.


A dialog ID is also associated with all responses and with any request
that contains a tag in the \header{To} field.  The rules for computing
the dialog ID of a message depend on whether the SIP element is a UAC or
UAS.  For a UAC, the \header{Call-ID} value of the dialog ID is set to
the \header{Call-ID} of the message, the remote tag is set to the
tag in the \header{To} field of the message, and the local tag is set to the
tag in the \header{From} field of the message (these rules apply to both requests
and responses).  As one would expect, for a UAS, the \header{Call-ID}
value of the dialog ID is set to the \header{Call-ID} of the message,
the remote tag is set to the tag in the \header{From} field of the message, and
the local tag is set to the tag in the \header{To} field of the
message.
\end{changebar}

A dialog contains certain pieces of state needed for further message
transmissions within the dialog.   This state
consists of the dialog ID, a local sequence number (used to order
requests from the UA to its peer), a remote sequence number (used to
order requests from its peer to the UA), a local URI, a remote URI,
the Contact URI of the peer, a boolean flag called ``secure'', and a route set, which is an
ordered list of URIs.   The  route set is the list
of servers that need to be traversed to send a request to the peer.
\begin{changebar} A
dialog can also be in the ``early'' state, which occurs when it is
created with a provisional response, and then transition to the
``confirmed'' state when a 2xx final response arrives. For other responses,
or if no response arrives at all on that dialog, the early dialog terminates.
\end{changebar}

\subsection{Creation of a Dialog}
\label{sec:dialog:creation}

Dialogs are created through the generation of non-failure responses to
requests with specific methods.  Within this specification, only 2xx and
101-199 responses with a \header{To} \header{tag} to {\INVITE} establish
a dialog.  A dialog established by a non-final response to a request is
in the ``early'' state and it is called an early dialog.  Extensions
{\MAY} define other means for creating dialogs.  Section~\ref{sec:initiate} 
gives more details that are specific to the {\INVITE}
method.  Here, we describe the process for creation of dialog state that
is not dependent on the method. 

UAs {\MUST} assign values to the dialog ID components as described below.

\subsubsection{UAS behavior}
\label{sec:dialog:construct:uas}

When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to {\INVITE}), the UAS {\MUST} copy all
\header{Record-Route} header field values from the request into the response
(including the URIs, URI parameters, and any \header{Record-Route}
header field parameters, whether they are known or unknown to the UAS) and
{\MUST} maintain the order of those values.   The UAS
{\MUST} add a \header{Contact} header field to the response.  The
\header{Contact} header field contains an address where the UAS would
like to be contacted for subsequent requests in the dialog (which
includes the {\ACK} for a 2xx response in the case of an {\INVITE}). 
Generally, the host portion of this URI is the IP address or FQDN of the
host.\begin{changebar} The URI provided in the \header{Contact} header
field {\MUST} be a SIP or SIPS URI.
If the request that initiated the dialog contained a SIPS URI in the
\header{Request-URI} or in the top \header{Record-Route} header field 
value, if there was any, or the \header{Contact} header field if there 
was no \header{Record-Route} header field, the \header{Contact} header 
field in the response {\MUST} be a SIPS URI. 
The URI {\SHOULD} have global scope 
(that is, the same URI can be used in messages outside this dialog).
The same way, the scope of the URI in the \header{Contact} header 
field of the {\INVITE} is not limited to this dialog either. 
It can therefore be used in messages to the UAC even outside this dialog.
\end{changebar}

The UAS then constructs the state of the dialog.  This state {\MUST} be
maintained for the duration of the dialog.  

\begin{changebar}
If the request arrived over TLS, and the \header{Request-URI} contained
a SIPS URI, the ``secure'' flag is set to TRUE.
\end{changebar}

The  route set {\MUST} be set to the list of URIs in the 
\header{Record-Route} header field from the request,
taken in order and preserving
all URI parameters. If no \header{Record-Route} header field is
present in the request, the  route set {\MUST} be set to the empty set. This
route set, even if empty,
overrides any pre-existing  route set for future requests
in this dialog. The remote target {\MUST} be set to the URI from the
\header{Contact} header field of the request. 

\begin{changebar}
The remote sequence number {\MUST} be set to the value of the sequence
number in the \header{CSeq} header field of the request.  The local sequence
number {\MUST} be empty.  The call identifier component of the dialog ID
{\MUST} be set to the value of the \header{Call-ID} in the request.  The
local tag component of the dialog ID {\MUST} be set to the
tag in the \header{To} field in the response to the request (which always
includes a tag), and the remote tag component of the dialog ID
{\MUST} be set to the tag from the \header{From} field in the request.  A UAS {\MUST}
be prepared to receive a request without a tag in the \header{From}
field, in which case the tag is considered to have a value of null. 
\motivation{This is to maintain backwards compatibility with RFC~2543,
which did not mandate \header{From} tags.}

The remote URI {\MUST} be set to the URI in the \header{From} field,
and the local URI {\MUST} be set to the URI in the \header{To} field.
\end{changebar}


\subsubsection{UAC Behavior}
\label{sec:dialog:construct:uac}

\begin{changebar}
When a UAC sends a request that can establish a dialog (such as an {\INVITE}) it {\MUST} provide a SIP or SIPS URI with global scope (i.e., the same SIP URI
can be used in messages outside this dialog) in the \header{Contact} header field of the request. If the request has a \header{Request-URI} or a topmost \header{Route} header field value with a 
SIPS URI, the \header{Contact} header field {\MUST} contain a SIPS URI.
\end{changebar}

When a UAC receives a response that establishes a dialog, it constructs
the state of the dialog.  This state {\MUST} be maintained for the
duration of the dialog. 

\begin{changebar}
If the request was sent over TLS, and the \header{Request-URI} contained
a SIPS URI, the ``secure'' flag is set to TRUE.
\end{changebar}

The route set {\MUST} be set to the list of URIs in the 
\header{Record-Route} header field from the response,
taken in reverse order and preserving
all URI parameters. If no \header{Record-Route} header field is
present in the response, the route set {\MUST} be set to the empty set. This
route set, even if empty,
overrides any pre-existing route set for future requests
in this dialog. The remote target {\MUST} be set to the URI from the
\header{Contact} header field of the response. 


The local sequence number {\MUST} be set to the value of the sequence
number in the \header{CSeq} header field of the request.  The remote sequence
number {\MUST} be empty (it is established when the remote UA sends a request
within the dialog).  \begin{changebar} The call identifier component of the dialog ID
{\MUST} be set to the value of the \header{Call-ID} in the request.  The
local tag component of the dialog ID {\MUST} be set to the
tag in the \header{From} field in the request, and the remote tag component of
the dialog ID {\MUST} be set to the tag in the \header{To} field of the response. 
A UAC {\MUST} be prepared to receive a response without a tag in the
\header{To} field, in which case the tag is considered to have a value
of null.  \motivation{This is to maintain backwards compatibility with
RFC~2543, which did not mandate \header{To} tags.}

The remote URI {\MUST} be set to the URI in the \header{To} field,
and the local URI {\MUST} be set to the URI in the \header{From} field.
\end{changebar}


\subsection{Requests within a Dialog}
\label{sec:midcalluac}

\begin{changebar}
Once a dialog has been established between two UAs, either of them
{\MAY} initiate new transactions as needed within the dialog.  
The UA sending the request will take the UAC role for the transaction.
The UA receiving the request will take the UAS role. Note that these
may be different roles than the UAs held during the transaction that
established the dialog.
\end{changebar}

Requests within a dialog {\MAY} contain \header{Record-Route} and
\header{Contact} header fields. However, these requests do not 
cause the dialog's route set to be modified, although they may 
modify the remote target URI. Specifically, requests that are 
not target refresh requests do not modify the dialog's remote 
target URI, and requests that are target refresh requests do. 
For dialogs that have been established with an {\INVITE}, the 
only target refresh request defined is re-{\INVITE} 
(see Section~\ref{sec:modify}). Other extensions may define different 
target refresh requests for dialogs established in other ways.
\motivation{Note that an {\ACK} is \emph{NOT} a target refresh request.

Target refresh requests only update the dialog's remote
target URI, and not the route set formed from
\header{Record-Route}.  Updating the latter would introduce severe
backwards compatibility problems with RFC~2543-compliant systems.}

\subsubsection{UAC Behavior}
\label{sec:dialog:uac}

\paragraph{Generating the Request}
\label{sec:dialog:uac:generate}

A request within a dialog is constructed by using many of the components
of the state stored as part of the dialog. 

\begin{changebar}
The URI in the \header{To} field of the request {\MUST} be set to the
remote URI from the dialog state. The tag in the \header{To} header field of
the request {\MUST} be set to the remote tag of the dialog ID. The
\header{From} URI of the request {\MUST} be set to the local URI from
the dialog state. The tag in the \header{From} header field of the
request {\MUST} be set to the local tag of the dialog ID. If the value
of the remote or local tags is null, the tag parameter {\MUST} be
omitted from the \header{To} or \header{From} header fields,
respectively. 

\motivation{Usage of the URI from the \header{To} and \header{From}
fields in the original request within subsequent requests is done for
backwards compatibility with RFC~2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection of the
original \header{To} and \header{From} URI in mid-dialog requests will
be deprecated in a subsequent revision of this specification.}
\end{changebar}

The \header{Call-ID} of the request {\MUST} be set to the
\header{Call-ID} of the dialog.  \begin{changebar} Requests within a dialog {\MUST}
contain strictly monotonically increasing and contiguous \header{CSeq}
sequence numbers (increasing-by-one) in each direction (excepting {\ACK}
and {\CANCEL} of course, whose numbers equal the requests being acknowledged
or cancelled).  \end{changebar} Therefore, if
the local sequence number is not empty, the value of the local sequence
number {\MUST} be incremented by one, and this value {\MUST} be placed into
the \header{CSeq} header field.  If the local sequence number is empty, an
initial value {\MUST} be chosen using the guidelines of 
Section~\ref{sec:general:uac:header:CSeq}.  The method field in the
\header{CSeq} header field value {\MUST} match the method of the request.

\motivation{With a length of 32 bits, a client could generate, within a
single call, one request a second for about 136 years before needing to
wrap around.  The initial value of the sequence number is chosen so that
subsequent requests within the same call will not wrap around.  A
non-zero initial value allows clients to use a time-based initial
sequence number.  A client could, for example, choose the 31 most
significant bits of a 32-bit second clock as an initial sequence
number.}


The UAC uses the remote target and route set to build
the \header{Request-URI} and \header{Route} header field of
the request.

If the route set is empty, the UAC {\MUST} place the
remote target URI into the \header{Request-URI}. The
UAC {\MUSTNOT} add a \header{Route} header field to the request.

If the route set is not empty, and the first URI in the route set 
contains the \header{lr} parameter (see 
Section~\ref{sec:sip-uri-components}), the UAC {\MUST} place the
remote target URI into the \header{Request-URI} and
{\MUST} include a \header{Route} header field containing the 
route set values in order, including all parameters.

If the route set is not empty, and its first URI
does not contain the \header{lr} parameter, the UAC 
{\MUST} place the first URI from the route set into 
the \header{Request-URI}, stripping any parameters
that are not allowed in a \header{Request-URI}.  The UAC
{\MUST} add a \header{Route} header field containing the
remainder of the route set values in order, including
all parameters. The UAC {\MUST} then place the
remote target URI into the \header{Route} header field
as the last value.

For example, if the remote target is sip:user@remoteua and the
route set contains
\begin{verbatim}
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
\end{verbatim}
The request will be formed with the following \header{Request-URI}
and \header{Route} header field:
\begin{verbatim}
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
\end{verbatim}

\motivation{
If the first URI of the route set does not contain the
\header{lr} parameter, the proxy indicated does not understand
the routing mechanisms described in this document
and will act as specified in RFC~2543, replacing the 
\header{Request-URI} with the first \header{Route} header field
value it receives while forwarding the message. Placing the
\header{Request-URI} at the end of the \header{Route} header field
preserves the information in that \header{Request-URI} across
the strict router (it will be returned to the \header{Request-URI}
when the request reaches a loose-router).
}

A UAC {\SHOULD} include a \header{Contact} header field in any target refresh
requests within a dialog, and unless there is a need to change it, the
URI {\SHOULD} be the same as used in previous requests within the
dialog.  \begin{changebar} If the ``secure'' flag is true, that URI {\MUST} be a SIPS URI. \end{changebar} As discussed in Section~\ref{sec:midcalluas}, a
\header{Contact} header field in a target refresh request updates the remote
target URI.  This allows a UA to provide a new contact address, should
its address change during the duration of the dialog.

However, requests that are not target refresh requests do not affect the
remote target URI for the dialog. 

\begin{changebar}
The rest of the request is formed as described in Section~\ref{sec:general:gen}.
\end{changebar}

Once the request has been constructed, the address of the server is
computed and the request is sent, using the same procedures for requests
outside of a dialog 
\begin{changebar}
(Section~\ref{sec:general:sending}). 

\motivation{
The procedures in Section~\ref{sec:general:sending} will normally result
in the request being sent to the address indicated by the topmost 
\header{Route} header field value or the \header{Request-URI} if no 
\header{Route} header field is present. Subject to certain restrictions, 
they allow the request to be sent to an alternate address (such as a 
default outbound proxy not represented in the route set).
}
\end{changebar}

\paragraph{Processing the Responses}
\label{sec:dialog:uac:response}

The UAC will receive responses to the request from the transaction
layer.  If the client transaction returns a timeout this is treated as a
408 (Request Timeout) response.


The behavior of a UAC that receives a 3xx response for a request sent
within a dialog is the same as if the request had been sent outside a
dialog.  This behavior is described in 
\begin{changebar}
Section~\ref{sec:ua:processing-3xx}.  
\end{changebar}

\motivation{Note, however, that when the
UAC tries alternative locations, it still uses the route set for
the dialog to build the \header{Route} header of the request.}


When a UAC receives a 2xx response to a target refresh request, it
{\MUST} replace the dialog's remote target URI with the URI from the
\header{Contact} header field in that response, if present.


If the response for a request within a dialog is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
{\SHOULD} terminate the dialog.  A UAC {\SHOULD} also terminate a dialog
if no response at all is received for the request (the client
transaction would inform the TU about the timeout.) 
\motivation{For {\INVITE} initiated dialogs, terminating the dialog
consists of sending a {\BYE}.}

\subsubsection{UAS Behavior}
\label{sec:midcalluas}


Requests sent within a dialog, as any other requests, are atomic.  If a
particular request is accepted by the UAS, \emph{all} the state changes
associated with it are performed.  If the request is rejected, 
\emph{none} of the state changes is performed.  \motivation{Note that some
requests such as {\INVITE}s affect several pieces of state.}


The UAS will receive the request from the transaction layer.  If the
request has a tag in the \header{To} header field, the UAS core computes
the dialog identifier corresponding to the request and compares it with
existing dialogs.  If there is a match, this is a mid-dialog request. 
In that case, the UAS first applies the same processing rules for requests
outside of a dialog, discussed in Section~\ref{sec:general:req-process}. 


If the request has a tag in the \header{To} header field, but the dialog
identifier does not match any existing dialogs, the UAS may have crashed
and restarted, or it may have received a request for a different
(possibly failed) UAS (the UASs can construct the \header{To} tags so
that a UAS can identify that the tag was for a UAS for which it is
providing recovery).  Another possibility is that the incoming request
has been simply misrouted.  Based on the \header{To} tag, the UAS
{\MAY} either accept or reject the request.  Accepting the request for
acceptable \header{To} tags provides robustness, so that dialogs can
persist even through crashes.  UAs wishing to support this capability
must take into consideration some issues such as choosing monotonically
increasing \header{CSeq} sequence numbers even across reboots,
reconstructing the route set, and accepting out-of-range RTP
timestamps and sequence numbers.

If the UAS wishes to reject the request, because it does not wish to
recreate the dialog, it {\MUST} respond to the request with a 481
(Call/Transaction Does Not Exist) status code and pass that to the
server transaction.  

Requests that do not change in any way the state of a dialog may be
received within a dialog (for example, an {\OPTIONS} request).  They are
processed as if they had been received outside the dialog.

If the remote sequence number is empty, it {\MUST} be set to the value
of the sequence number in the \header{CSeq} header field value in the request.  If
the remote sequence number was not empty, but the sequence number of the
request is lower than the remote sequence number, the request is out of
order and {\MUST} be rejected with a 500 (Server Internal Error)
response.  If the remote sequence number was not empty, and the sequence
number of the request is greater than the remote sequence number, the
request is in order.  It is possible for the \header{CSeq} sequence number to be
higher than the remote sequence number by more than one.  This is not an
error condition, and a UAS {\SHOULD} be prepared to receive and process
requests with \header{CSeq} values more than one higher than the
previous received request.  The UAS {\MUST} then set the remote sequence
number to the value of the sequence number in the \header{CSeq} header field value
in the request.   \motivation{If a proxy challenges a
request generated by the UAC, the UAC has to resubmit the request with
credentials.  The resubmitted request will have a new \header{CSeq}
number.  The UAS will never see the first request, and thus, it will
notice a gap in the \header{CSeq} number space.  Such a gap does not
represent any error condition.} 

\begin{changebar}
When a UAS receives a target refresh request, it
{\MUST} replace the dialog's remote target URI with the URI from the
\header{Contact} header field in that request, if present.
\end{changebar}


\subsection{Termination of a Dialog}
\label{sec:dialog:termination}

\begin{changebar}
Independent of the method, if a request outside of a dialog generates
a non-2xx final response, any early dialogs created through provisional
responses to that request are terminated. The mechanism for
terminating confirmed dialogs is method specific. In this specification, 
the {\BYE} method terminates a session and the dialog associated with it.
See Section~\ref{sec:terminate} for details.
\end{changebar}
