\section{Modifying an Existing Session}
\label{sec:modify}

A successful {\INVITE} request (see Section~\ref{sec:initiate})
establishes both a dialog between two user agents and a session using
the offer-answer model.  Section~\ref{sec:dialog} explains how to
modify an existing dialog using a target refresh request (for example, 
changing the remote target URI of the dialog).
This section describes how to
modify the actual session.  This modification can involve changing
addresses or ports, adding a media stream, deleting a media stream, and
so on.  This is accomplished by sending a new {\INVITE} request within
the same dialog that established the session.  An {\INVITE} request sent
within an existing dialog is known as a re-{\INVITE}. 

\motivation{Note that a single re-{\INVITE} can modify 
the dialog and the parameters of the session at the same time.}

Either the caller or callee can modify an existing session.

The behavior of a UA on detection of media failure is a matter of local
policy.  However, automated generation of re-{\INVITE} or {\BYE} is
{\NOTRECOMMENDED} to avoid flooding the network with traffic when there
is congestion.  In any case, if these messages are sent automatically,
they {\SHOULD} be sent after some randomized interval.  \motivation{Note
that the paragraph above refers to automatically generated {\BYE}s and
re-{\INVITE}s.  If the user hangs up upon media failure the UA would
send a {\BYE} request as usual.}

\subsection{UAC Behavior}
\label{sec:modifyuac}

The same offer-answer model that applies to session descriptions in
{\INVITE}s (Section~\ref{sec:initiateuac}) applies to re-{\INVITE}s. 
As a result, a UAC that wants to add a media stream, for example, will
create a new offer that contains this media stream, and send that in an
{\INVITE} request to its peer.  It is important to note that the full
description of the session, not just the change, is sent.  This
supports stateless session processing
in various elements, and supports failover and recovery capabilities. 
\begin{changebar} Of course, a UAC {\MAY} send a re-{\INVITE} with no session description,
in which case the first reliable non-failure response to the re-{\INVITE} will contain the offer (in this specification, that is a 2xx response).  \end{changebar}

If the session description format has the capability for version
numbers, the offerer {\SHOULD} indicate that the version of the session
description has changed. 

The \header{To}, \header{From}, \header{Call-ID}, \header{CSeq}, and
\header{Request-URI} of a re-{\INVITE} are set following the same rules
as for regular requests within an existing dialog, described in
Section~\ref{sec:dialog}.

A UAC {\MAY} choose not to add an \header{Alert-Info} header field or
a body with \header{Content-Disposition} ''alert'' to re-{\INVITE}s
because UASs do not typically alert the user upon reception of a
re-{\INVITE}. 

\begin{changebar}
Unlike an {\INVITE}, which can fork, a re-{\INVITE} will never fork,
and therefore, only ever generate a single final response. The reason a
re-{\INVITE} will never fork is that the \header{Request-URI}
identifies the target as the UA instance it established the dialog
with, rather than identifying an address-of-record for the user.
\end{changebar}

\begin{changebar}
Note that a UAC {\MUSTNOT} initiate a new {\INVITE} transaction within a
dialog while another {\INVITE} transaction is in progress in either direction.

\begin{enumerate}
\item If there is an ongoing {\INVITE} client transaction, the TU {\MUST} wait until the transaction reaches the \emph{completed} or \emph{terminated} state before initiating the new {\INVITE}.

\item If there is an ongoing {\INVITE} server transaction, the TU {\MUST}
wait until the transaction reaches the \emph{confirmed} or 
\emph{terminated} state before initiating the new {\INVITE}.
\end{enumerate}

However, a UA {\MAY} initiate a regular transaction while an {\INVITE}
transaction is in progress. A UA {\MAY} also initiate an {\INVITE} transaction while a regular transaction is in progress.
\end{changebar}

If a UA receives a non-2xx final response to a re-{\INVITE}, the session
parameters {\MUST} remain unchanged, as if no re-{\INVITE} had been
issued.  Note that, as stated in Section~\ref{sec:dialog:uac:response},
if the non-2xx final response is a 481 (Call/Transaction Does Not Exist),
or a 408 (Request Timeout), or no response at all is received for the
re-{\INVITE} (that is, a timeout is returned by the {\INVITE} client transaction),
the UAC will terminate the dialog.  

The rules for transmitting a re-{\INVITE} and for generating an {\ACK}
for a 2xx response to re-{\INVITE} are the same as for the initial {\INVITE}
(Section~\ref{sec:initiateuac}).

\subsection{UAS Behavior}
\label{sec:modifyuas}

Section~\ref{sec:initiateuas} describes the procedure for  
distinguishing incoming re-{\INVITE}s from incoming initial {\INVITE}s 
and handling a re-{\INVITE} for an existing dialog.

A UAS that receives a second {\INVITE} before it sends the final response
to a first {\INVITE} with a lower \header{CSeq} sequence number on the
same dialog {\MUST} return a 500 (Server Internal Error) response to the
second {\INVITE} and {\MUST} include a \header{Retry-After} header field
with a randomly chosen value of between 0 and 10 seconds.

A UAS that receives an {\INVITE} on a dialog while an {\INVITE} it had
sent on that dialog is in progress {\MUST} return a 491 (Request
Pending) response to the received {\INVITE} and {\MUST} include a
\header{Retry-After} header field with a value chosen as follows:

\begin{enumerate}
\item If the UAS is the owner of the \header{Call-ID} of the dialog ID
(meaning it generated the value),
the \header{Retry-After} header field has a randomly chosen value of
between 2.1 and 4 seconds in units of 10\,ms.
 
\item If the UAS is \emph{not} the owner of the \header{Call-ID} of the
dialog ID, the \header{Retry-After} header field has a randomly chosen
value of between 0 and 2 seconds in units of 10\,ms.  \end{enumerate}


If a UA receives a re-{\INVITE} for an existing dialog, 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.  If the session description has changed, the
UAS {\MUST} adjust the session parameters accordingly,
possibly after asking the user for confirmation.  \motivation{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 the new session
description is not acceptable, the UAS can reject it by returning a 488
(Not Acceptable Here) response for the re-{\INVITE}.  This response
{\SHOULD} include a \header{Warning} header field.

If a UAS generates a 2xx response and never receives an {\ACK}, it
{\SHOULD} generate a {\BYE} to terminate the dialog.

A UAS {\MAY} choose not to generate 180 (Ringing) responses for a
re-{\INVITE} because UACs do not typically render this information to
the user.  For the same reason, UASs {\MAY} choose not to use
an \header{Alert-Info} header field or a body with
\header{Content-Disposition} ''alert'' in responses to a re-{\INVITE}.  


A UAS providing an offer in a 2xx (because the {\INVITE} did not contain
an offer) {\SHOULD} construct the offer as if the UAS were making a
brand new call, subject to the constraints of sending an offer that 
updates an existing session, as described
in~\citenorm{draft-ietf-mmusic-sdp-offer-answer} in the case of SDP. Specifically, this means
that it {\SHOULD} include as many media formats and media types that
the UA is willing to support. The UAS {\MUST} ensure that the session
description overlaps with its previous session description in media formats, transports, or other parameters
that require support from the peer. This is to avoid the need for the
peer to reject the session description. If, however, it is
unacceptable to the UAC, the UAC {\SHOULD} generate an answer with a
valid session description, and then send a {\BYE} to terminate the session.



