\section{Terminating a Session}
\label{sec:terminate}

\begin{changebar}
This section describes the procedures for terminating a session
established by SIP. The state of the session and the state of the
dialog are very closely related. When a session is initiated with an
{\INVITE}, each 1xx or 2xx response from a distinct UAS creates a
dialog, and if that response completes the offer/answer exchange, it
also creates a session. As a result, each session is ``associated''
with a single dialog - the one which resulted in its creation. If an
initial {\INVITE} generates a non-2xx final response, that terminates
all sessions (if any) and all dialogs (if any) that were created
through responses to the request. By virtue of completing the
transaction, a non-2xx final response also prevents further sessions
from being created as a result of the {\INVITE}. The {\BYE} request is
used to terminate a specific session or attempted session. 
In this case, the specific session is the one with the
peer UA on the
other side of the dialog. When a {\BYE} is received on a dialog, 
any session associated with that dialog {\SHOULD} terminate. A UA
{\MUSTNOT} send a {\BYE} outside of a dialog. The caller's UA {\MAY} send a
{\BYE} for either confirmed or early dialogs, and the callee's UA {\MAY} send
a {\BYE} on confirmed dialogs, but {\MUSTNOT} send a {\BYE} on early
dialogs. However, the callee's UA {\MUSTNOT} send a {\BYE} on a confirmed
dialog until it has received an {\ACK} for its 2xx response or until
the server transaction times out. If no SIP extensions have defined
other application layer state associated with the dialog, the {\BYE}
also terminates the dialog.

The impact of a non-2xx final response to {\INVITE} on dialogs and
sessions makes the use of {\CANCEL} attractive. The {\CANCEL} attempts
to force a non-2xx response to the {\INVITE} (in particular, a
487). Therefore, if a UAC wishes to give up on its call attempt
entirely, it can send a {\CANCEL}. If the {\INVITE} results in 2xx
final response(s) to the {\INVITE}, this means that a UAS accepted the
invitation while the {\CANCEL} was in progress. The UAC {\MAY}
continue with the sessions established by any 2xx responses, or {\MAY}
terminate them with {\BYE}. 

\motivation{The notion of ``hanging up'' is not well defined within SIP. It is
specific to a particular, albeit common, user interface. Typically,
when the user hangs up, it indicates a desire to terminate the attempt
to establish a session, and to terminate any sessions already
created. For the caller's UA, this would imply a {\CANCEL} request if the
initial {\INVITE} has not generated a final response, and a {\BYE} to
all confirmed dialogs after a final response. For the callee's UA, it would
typically imply a {\BYE}; presumably, when the user picked up the
phone, a 2xx was generated, and so hanging up would result in a {\BYE}
after the {\ACK} is received. This does not mean a user cannot hang up
before receipt of the {\ACK}, it just means that the software in his
phone needs to maintain state for a short while in order to clean up
properly. If the particular UI allows for the user to reject a call
before its answered, a 403 (Forbidden) is a good way to express
that. As per the rules above, a {\BYE} can't be sent.}

\subsection{Terminating a Session with a {\BYE} Request}
\label{sec:terminatebye}

\subsubsection{UAC Behavior}
\label{sec:byeuac}

A {\BYE} request is constructed as would any other request within a
dialog, as described in Section~\ref{sec:dialog}. 

Once the {\BYE} is constructed, the UAC core creates a new non-{\INVITE} client
transaction, and passes it the {\BYE} request.  The UAC {\MUST}
consider the session terminated (and therefore stop sending or
listening for media) as soon as the {\BYE} request is passed to the client
transaction.  If the response for the {\BYE} is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
response at all is received for the {\BYE} (that is, a timeout is returned by the
client transaction), the UAC {\MUST} consider the session and the dialog
terminated. 

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

A UAS first processes the {\BYE} request according to the general UAS
processing described in Section~\ref{sec:general:req-process}.  A UAS
core receiving a {\BYE} request checks if it matches an existing
dialog.  If the {\BYE} does not match an existing dialog, the UAS core
{\SHOULD} generate a 481 (Call/Transaction Does Not Exist) response and
pass that to the server transaction.

\motivation{This rule means that a {\BYE} sent without tags by a UAC
will be rejected.  This is a change from RFC~2543, which allowed {\BYE}
without tags.}

A UAS core receiving a {\BYE} request for an existing dialog {\MUST}
follow the procedures of Section~\ref{sec:midcalluas} to process the
request.  Once done, the UAS {\SHOULD} terminate the session (and
therefore stop sending and listening for media). The only
case where it can elect not to are multicast sessions, where
participation is possible even if the other participant in the dialog
has terminated its involvement in the session. Whether or not it ends
its participation on the session, the UAS core {\MUST} generate a 2xx
response to the {\BYE}, and {\MUST} pass that to the server transaction
for transmission.

The UAS {\MUST} still respond to any pending requests received for that
dialog.  It is {\RECOMMENDED} that a
487 (Request Terminated) response is generated to those pending
requests. 

\end{changebar}

