\section{Transactions}
\label{sec:transactions}

SIP is a transactional protocol: interactions between components take
place in a series of independent message exchanges.  Specifically, a
SIP transaction consists of a single request and any responses to
that request, which include zero or more provisional responses and one
or more final responses. In the case of a transaction where the
request was an {\INVITE} (known as an {\INVITE} transaction), the
transaction also includes the {\ACK} only if the final response was
not a 2xx response.  If the response was a 2xx, the {\ACK} is not
considered part of the transaction.  \motivation{The reason for this
separation is rooted in the importance of delivering all 200 (OK)
responses to an {\INVITE} to the UAC.  To deliver them all to the UAC,
the UAS alone takes responsibility for retransmitting them (see
Section~\ref{sec:initiateuas:accept}), and the UAC alone takes
responsibility for acknowledging them with {\ACK} 
(see Section~\ref{sec:initiateresponses:2xx}).  
Since this {\ACK} is retransmitted
only by the UAC, it is effectively considered its own transaction.}

Transactions have a client side and a server side.  The client side is
known as a client transaction and the server side as a server
transaction.  The client transaction sends the request, and the server
transaction sends the response.  The client and server transactions are
logical functions that are embedded in any number of elements. 
Specifically, they exist within user agents and stateful proxy servers. 
Consider the example in Section~\ref{sec:overview-of-operations}.  In
this example, the UAC executes the client transaction, and its outbound
proxy executes the server transaction.  The outbound proxy also executes
a client transaction, which sends the request to a server transaction in
the inbound proxy.  That proxy also executes a client transaction, which
in turn sends the request to a server transaction in the UAS.  This is
shown in Figure~\ref{fig:tmodel}.

\txtpsfigsize{!}{!}{tmodel}{Transaction relationships}

A stateless proxy does not contain a client or server transaction.  The
transaction exists between the UA or stateful proxy on one side,
and the UA or stateful proxy on the other side.  As far
as SIP transactions are concerned, stateless proxies are effectively
transparent.  The purpose of the client transaction is to receive a
request from the element in which the client is embedded (call this element
the ``Transaction User'' or TU; it can be a UA or a stateful proxy), and
reliably deliver the request to a server transaction.  The client
transaction is also responsible for receiving responses and delivering
them to the TU, filtering out any response retransmissions or disallowed
responses (such as a response to {\ACK}). Additionally, in the case 
of an {\INVITE} request, the client transaction is responsible 
for generating the {\ACK} request for any final response excepting 
a 2xx response.

Similarly, the purpose of the server transaction is to receive requests
from the transport layer and deliver them to the TU.  The server
transaction filters any request retransmissions from the network.  The
server transaction accepts responses from the TU and delivers them to
the transport layer for transmission over the network.  In the case of
an {\INVITE} transaction, it absorbs the {\ACK} request for any final
response excepting a 2xx response.

The 2xx response and its {\ACK} receive special treatment.  This
response is retransmitted only by a UAS, and its {\ACK} generated only
by the UAC.  This end-to-end treatment is needed so that a caller knows
the entire set of users that have accepted the call.  Because of this
special handling, retransmissions of the 2xx response are handled by the
UA core, not the transaction layer.  Similarly, generation of the {\ACK}
for the 2xx is handled by the UA core.  Each proxy along the path merely
forwards each 2xx response to {\INVITE} and its corresponding {\ACK}.

\subsection{Client Transaction}
\label{sec:transactions:client}

The client transaction provides its functionality through the
maintenance of a state machine.

The TU communicates with the client transaction through a simple
interface.  When the TU wishes to initiate a new transaction, it creates
a client transaction and passes it the SIP request to send and an IP
address, port, and transport to which to send it. The client transaction
begins execution of its state machine.  Valid responses are passed up to
the TU from the client transaction.

There are two types of client transaction state machines, depending on
the method of the request passed by the TU.  One handles client
transactions for {\INVITE} requests.  This type of machine is referred to
as an {\INVITE} client transaction.  Another type handles client
transactions for all requests except {\INVITE} and {\ACK}.  This is
referred to as a non-{\INVITE} client transaction.  There is no client
transaction for {\ACK}.  If the TU wishes to send an {\ACK}, it passes
one directly to the transport layer for transmission.

The {\INVITE} transaction is different from those of other methods
because of its extended duration.  Normally, human input is required in
order to respond to an {\INVITE}.  The long delays expected for sending
a response argue for a three-way handshake.  On the other hand, requests 
of other methods are expected to complete rapidly.  Because
of the non-{\INVITE} transaction's reliance on a two-way handshake, 
TUs {\SHOULD} respond immediately to non-{\INVITE} requests.  

\subsubsection{{\INVITE} Client Transaction}
\label{sec:transactions:client:invite}

\paragraph{Overview of {\INVITE} Transaction}
\label{sec:transactions:client:invite:overview}

The {\INVITE} transaction consists of a three-way handshake.  The client
transaction sends an {\INVITE}, the server transaction sends responses,
and the client transaction sends an {\ACK}.  For unreliable transports
(such as UDP), the client transaction retransmits requests at an
interval that starts at T1 seconds and doubles after every
retransmission.  T1 is an estimate of the round-trip time (RTT), 
and it defaults to
500\,ms.  Nearly all of the transaction timers described here scale with
T1, and changing T1 adjusts their values.  The request is
not retransmitted over reliable transports.  After receiving a 1xx
response, any retransmissions cease altogether, and the client waits for
further responses.  The server transaction can send additional 1xx
responses, which are not transmitted reliably by the server transaction. 
Eventually, the server transaction decides to send a final
response.  For unreliable transports, that response is retransmitted
periodically, and for reliable transports, it is sent once.  For each
final response that is received at the client transaction, the client
transaction sends an {\ACK}, the purpose of which is to quench
retransmissions of the response.

\paragraph{Formal Description}
\label{sec:transactions:client:invite:formal}

\txtpsfigsize{!}{!}{invite-client}{{\INVITE} client transaction}

The state machine for the {\INVITE} client transaction is shown in
Figure~\ref{fig:invite-client}.  The initial state, ``calling'', {\MUST}
be entered when the TU initiates a new client transaction with an
{\INVITE} request.  The client transaction {\MUST} pass the request to
the transport layer for transmission (see Section~\ref{sec:transport}). 
If an unreliable transport is being used, the client transaction
{\MUST} start timer A with a value of T1. If a reliable transport
is being used, the client transaction {\SHOULDNOT} start
timer A (Timer A controls
request retransmissions).  For any transport, the client transaction
{\MUST} start timer B with a value of 64*T1 seconds (Timer B controls
transaction timeouts).

When timer A fires, the client transaction {\MUST} retransmit the
request by passing it to the transport layer, and {\MUST} reset the
timer with a value of 2*T1.  The formal definition of {\em retransmit}
within the context of the transaction layer is to take the message
previously sent to the transport layer and pass it to the transport
layer once more. 

When timer A fires 2*T1 seconds later, the request {\MUST} be
retransmitted again (assuming the client transaction is still in this
state).  This process {\MUST} continue so that the request is
retransmitted with intervals that double after each transmission.  These
retransmissions {\SHOULD} only be done while the client transaction is
in the ``calling'' state.

\begin{changebar}
The default value for T1 is 500\,ms.  T1 is an estimate of the RTT
between the client and server transactions.  Elements {\MAY} (though
it is {\NOTRECOMMENDED}) use smaller values of T1 within closed,
private networks that do not permit general Internet connection. T1
{\MAY} be chosen larger, and this is {\RECOMMENDED} if it is known in
advance (such as on high latency access links) that the RTT is
larger. Whatever the value of T1, the exponential backoffs on
retransmissions described in this section {\MUST} be used.
\end{changebar}

If the client transaction is still in the ``calling'' state when timer B
fires, the client transaction {\SHOULD } inform the TU that a timeout
has occurred.  The client transaction {\MUSTNOT} generate an {\ACK}. 
The value of 64*T1 is equal to the amount of time required to send seven
requests in the case of an unreliable transport.

If the client transaction receives a provisional response while in the
''Calling'' state, it transitions to the ``proceeding'' state.  In the
``proceeding'' state, the client transaction {\SHOULDNOT} retransmit the
request any longer.  Furthermore, the provisional response {\MUST} be
passed to the TU.  Any further provisional responses {\MUST} be passed
up to the TU while in the ``proceeding'' state.  

When in either the ''Calling'' or ``Proceeding'' states, reception of a
response with status code from 300-699 {\MUST} cause the client
transaction to transition to ``Completed''.  The client transaction
{\MUST} pass the received response up to the TU, and the client
transaction {\MUST} generate an {\ACK} request, even if the transport is
reliable (guidelines for constructing the {\ACK} from the response are
given in Section~\ref{sec:transactions:client:invite:ack}) and then pass
the {\ACK} to the transport layer for transmission.  The {\ACK} {\MUST}
be sent to the same address, port, and transport to which the original
request was sent.  The client transaction {\SHOULD } start timer D
when it enters the ``Completed'' state, with a value of at least 32
seconds for unreliable transports, and a value of zero seconds for
reliable transports.  Timer D reflects the amount of time that
the server transaction can remain in the ``Completed'' state when
unreliable transports are used.  This is equal to Timer H in the
{\INVITE} server transaction, whose default is 64*T1.  However, the
client transaction does not know the value of T1 in use by the server
transaction, so an absolute minimum of 32s is used instead of basing
Timer D on T1. 

Any retransmissions of the final response that are received while in the
``Completed'' state {\MUST} cause the {\ACK} to be re-passed to the
transport layer for retransmission, but the newly received response
{\MUSTNOT} be passed up to the TU.  A retransmission of the response is
defined as any response which would match the same client transaction
based on the rules of Section~\ref{sec:transactions:client:match}.

If timer D fires while the client transaction is in the ``Completed''
state, the client transaction {\MUST} move to the terminated state, and
it {\MUST} inform the TU of the timeout.

When in either the ``Calling'' or ``Proceeding'' states, reception of a
2xx response {\MUST} cause the client transaction to enter the
''Terminated'' state, and the response {\MUST} be passed up to the TU.  The
handling of this response depends on whether the TU is a proxy core or a
UAC core.  A UAC core will handle generation of the {\ACK} for this
response, while a proxy core will always forward the 200 (OK) upstream. 
The differing treatment of 200 (OK) between proxy and UAC is the reason
that handling of it does not take place in the transaction layer.

The client transaction {\MUST} be destroyed the instant it enters the
''Terminated'' state.  This is actually necessary to guarantee correct
operation.  The reason is that 2xx responses to an {\INVITE} are treated
differently; each one is forwarded by proxies, and the {\ACK} handling
in a UAC is different.  Thus, each 2xx needs to be passed to a proxy
core (so that it can be forwarded) and to a UAC core (so it can be
acknowledged).  No transaction layer processing takes place.  Whenever a
response is received by the transport, if the transport layer finds no
matching client transaction (using the rules of 
Section~\ref{sec:transactions:client:match}), the response is passed 
directly to the core.  Since the matching client transaction is destroyed by the
first 2xx, subsequent 2xx will find no match and therefore be passed to
the core.

\paragraph{Construction of the {\ACK} Request}
\label{sec:transactions:client:invite:ack}

This section specifies the construction of {\ACK} requests sent within 
the client transaction.  A UAC core that generates an {\ACK} 
for 2xx {\MUST} instead follow the rules described in 
Section~\ref{sec:initiate}.  

The {\ACK} request constructed by the client transaction {\MUST} contain
values for the \header{Call-ID}, \header{From}, and \header{Request-URI}
that are equal to the values of those header fields in the request
passed to the transport by the client transaction (call this the
``original request'').  The \header{To} header field in the {\ACK}
{\MUST} equal the \header{To} header field in the response being
acknowledged, and therefore will usually differ from the \header{To}
header field in the original request by the addition of the tag
parameter.  The {\ACK} {\MUST} contain a single \header{Via} header
field, and this {\MUST} be equal to the top \header{Via} header field of
the original request. The \header{CSeq} header field in the {\ACK} {\MUST}
contain the same value for the sequence number as was present in the
original request, but the method parameter {\MUST} be equal to
``{\ACK}''.

If the {\INVITE} request whose response is being acknowledged had
\header{Route} header fields, those header fields {\MUST} appear in the {\ACK}. 
This is to ensure that the {\ACK} can be routed properly through any
downstream stateless proxies.

Although any request {\MAY} contain a body, a body in an {\ACK} is
special since the request cannot be rejected if the body is not
understood.  Therefore, placement of bodies in {\ACK} for non-2xx is
{\NOTRECOMMENDED}, but if done, the body types are restricted to any
that appeared in the {\INVITE}, assuming that the response to the
{\INVITE} was not 415.  If it was, the body in the {\ACK} {\MAY} be any
type listed in the \header{Accept} header field in the 415.

For example, consider the following request:

\begin{verbatim}
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
\end{verbatim}

The {\ACK} request for a non-2xx final response to this request would
look like this:

\begin{verbatim}
ACK sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
\end{verbatim}

\subsubsection{Non-{\INVITE} Client Transaction}
\label{sec:trans:client:noninv}

\paragraph{Overview of the non-{\INVITE} Transaction}
\label{sec:trans:client:noninv:overview}

Non-{\INVITE} transactions do not make use of {\ACK}.  They are simple
request-response interactions.  For unreliable transports, requests are
retransmitted at an interval which starts at T1 and doubles until it
hits T2.  If a provisional response is received, retransmissions
continue for unreliable transports, but at an interval of T2.  The
server transaction retransmits the last response it sent, which can be a
provisional or final response, only when a retransmission of the request
is received.  This is why request retransmissions need to continue even
after a provisional response, they are to ensure reliable delivery of
the final response.

Unlike an {\INVITE} transaction, a non-{\INVITE} transaction has no
special handling for the 2xx response.  The result is that only a single
2xx response to a non-{\INVITE} is ever delivered to a UAC.

\paragraph{Formal Description}
\label{sec:trans:client:noninv:formal}

\txtpsfigsize{!}{!}{noninvite-client}{non-{\INVITE} client transaction}

The state machine for the non-{\INVITE} client transaction is shown in
Figure~\ref{fig:noninvite-client}.  It is very similar to the state
machine for {\INVITE}.

The ``Trying'' state is entered when the TU initiates a new client
transaction with a request.  When entering this state, the client
transaction {\SHOULD} set timer F to fire in 64*T1 seconds.  The request
{\MUST} be passed to the transport layer for transmission.  If an
unreliable transport is in use, the client transaction {\MUST} set timer
E to fire in T1 seconds.  If timer E fires while still in this state,
the timer is reset, but this time with a value of MIN(2*T1, T2).  When
the timer fires again, it is reset to a MIN(4*T1, T2).  This process
continues so that retransmissions occur with an exponentially
increasing interval that caps at T2.  The default value of T2 is 4s, and
it represents the amount of time a non-{\INVITE} server transaction will
take to respond to a request, if it does not respond immediately.  For
the default values of T1 and T2, this results in intervals of 500\,ms,
1\,s, 2\,s, 4\,s, 4\,s, 4\,s, etc.

If Timer F fires while the client transaction is still in the ``Trying''
state, the client transaction {\SHOULD} inform the TU about the timeout,
and then it {\SHOULD } enter the ``Terminated'' state.  If a provisional
response is received while in the ``Trying'' state, the response {\MUST}
be passed to the TU, and then the client transaction {\SHOULD} move to
the ``Proceeding'' state.  If a final response (status codes 200-699) is
received while in the ``Trying'' state, the response {\MUST} be passed
to the TU, and the client transaction {\MUST} transition to the
``Completed'' state.

If Timer E fires while in the ``Proceeding'' state, the request {\MUST}
be passed to the transport layer for retransmission, and Timer E {\MUST}
be reset with a value of T2 seconds.  If timer F fires while in the
``Proceeding'' state, the TU {\MUST} be informed of a timeout, and the
client transaction {\MUST} transition to the terminated state.  If a
final response (status codes 200-699) is received while in the
``Proceeding'' state, the response {\MUST} be passed to the TU, and the
client transaction {\MUST} transition to the ``Completed'' state.

Once the client transaction enters the ``Completed'' state, it {\MUST}
set Timer K to fire in T4 seconds for unreliable transports, and zero
seconds for reliable transports.  The ``Completed'' state exists to
buffer any additional response retransmissions that may be received
(which is why the client transaction remains there only for unreliable
transports).  T4 represents the amount of time the network will take to
clear messages between client and server transactions.  The default
value of T4 is 5s.  A response is a retransmission when it matches the
same transaction, using the rules specified in 
Section~\ref{sec:transactions:client:match}.  If Timer K fires while in this
state, the client transaction {\MUST} transition to the ``Terminated''
state.

Once the transaction is in the terminated state, it {\MUST} be
destroyed. 

\subsubsection{Matching Responses to Client Transactions}
\label{sec:transactions:client:match}

When the transport layer in the client receives a response, it has to
determine which client transaction will handle the response, so that
the processing of Sections~\ref{sec:transactions:client:invite} 
and~\ref{sec:trans:client:noninv} can take place.
The branch parameter in the top \header{Via} header field is used for this
purpose.  A response matches a client transaction under two conditions: 
\begin{enumerate}
\item If the response has the same value of the branch parameter in the
top \header{Via} header field as the branch parameter in the top \header{Via}
header field of the request that created the transaction.  
\item If the method parameter in the \header{CSeq} header field matches 
the method of the request that created the transaction.  The method 
is needed since a
{\CANCEL} request constitutes a different transaction, but shares the
same value of the branch parameter.
\end{enumerate}

A response that matches a transaction matched by a previous response is
considered a retransmission of that response. 

\begin{changebar}
If a request is sent via multicast, it is possible that it will
generate multiple responses from different servers. These responses
will all have the same branch parameter in the topmost \header{Via},
but vary in the \header{To} tag. The first response received, based on
the rules above, will be used, and others will be viewed as
retransmissions. That is not an error; multicast SIP provides only a
rudimentary ``single-hop-discovery-like'' service that is limited to
processing a single response. See 
Section~\ref{sec:transport:clients:sending} for details.
\end{changebar}

\subsubsection{Handling Transport Errors}
\label{sec:transactions:client:error}

When the client transaction sends a request to the transport layer to be
sent, the following procedures are followed if the transport layer
indicates a failure.

The client transaction {\SHOULD} inform the TU that a transport
failure has occurred, and the client transaction {\SHOULD} transition
directly to the ''Terminated'' state. \begin{changebar} The TU will handle
the failover mechanisms described in~\citenorm{draft-ietf-sip-srv}.
\end{changebar}

\subsection{Server Transaction}
\label{sec:transactions:server}

The server transaction is responsible for the delivery of requests to
the TU and the reliable transmission of responses. It accomplishes
this through a state machine. Server transactions are created by the
core when a request is received, and transaction handling is desired
for that request (this is not always the case).

As with the client transactions, the state machine depends on whether
the received request is an {\INVITE} request.

\subsubsection{{\INVITE} Server Transaction}
\label{sec:transactions:server:invite}

\txtpsfigsize{!}{!}{invite-server}{{\INVITE} server transaction}

The state diagram for the {\INVITE} server transaction is shown in 
Figure~\ref{fig:invite-server}.

When a server transaction is constructed with a request, it enters the
``Proceeding'' state.  The server transaction {\MUST} generate a 100
(Trying) response unless it
knows that the TU will generate a provisional or final response within
200\,ms, in which case it {\MAY} generate a 100 (Trying) response.  This
provisional response is needed to quench request retransmissions rapidly
in order to avoid network congestion.  The 100 (Trying) response is constructed
according to the procedures in Section~\ref{sec:general:serv-resp},
except that the insertion of tags in the \header{To} header field 
of the response (when none was present in the request) is downgraded 
from {\MAY} to {\SHOULDNOT}.  The request {\MUST} be passed to the TU.

The TU passes any number of provisional responses to the server
transaction.  So long as the server transaction is in the ``Proceeding''
state, each of these {\MUST} be passed to the transport layer for
transmission.  They are not sent reliably by the transaction layer (they
are not retransmitted by it) and do not cause a change in the state of
the server transaction.  If a request retransmission is received while in the
``Proceeding'' state, the most recent provisional response that was
received from the TU {\MUST} be passed to the transport layer for
retransmission.  A request is a retransmission if it matches the same
server transaction based on the rules of 
Section~\ref{sec:transactions:server:match}.

If, while in the ``Proceeding'' state, the TU passes a 2xx response to
the server transaction, the server transaction {\MUST} pass this
response to the transport layer for transmission.  It is not
retransmitted by the server transaction; retransmissions of 2xx
responses are handled by the TU.  The server transaction {\MUST} then
transition to the ``Terminated'' state.

While in the ``Proceeding'' state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
{\MUST} be passed to the transport layer for transmission, and the state
machine {\MUST} enter the ``Completed'' state.  For unreliable
transports, timer G is set to fire in T1 seconds, and is not set to fire
for reliable transports.

\motivation{This is a change from RFC~2543, where responses were always 
retransmitted, even over reliable transports.}

When the ``Completed'' state is entered, timer H {\MUST} be set to fire
in 64*T1 seconds for all transports.  Timer H determines when the
server transaction abandons retransmitting the response.  Its value is
chosen to equal Timer B, the amount of time a client transaction will
continue to retry sending a request.  If timer G fires, the response is
passed to the transport layer once more for retransmission, and timer G
is set to fire in MIN(2*T1, T2) seconds.  From then on, when timer G
fires, the response is passed to the transport again for transmission,
and timer G is reset with a value that doubles, unless that value
exceeds T2, in which case it is reset with the value of T2.  This is
identical to the retransmit behavior for requests in the ``Trying''
state of the non-{\INVITE} client transaction.  Furthermore, while in
the ``Completed'' state, if a request retransmission is received, the
server {\SHOULD} pass the response to the transport for retransmission.

If an {\ACK} is received while the server transaction is in the
``Completed'' state, the server transaction {\MUST} transition to the
``Confirmed'' state.  As Timer G is ignored in this state, any
retransmissions of the response will cease.

If timer H fires while in the ``Completed'' state, it implies that the
{\ACK} was never received.  In this case, the server transaction {\MUST}
transition to the ''Terminated'' state, and {\MUST} indicate to the TU that
a transaction failure has occurred.

The purpose of the ``Confirmed'' state is to absorb any additional
{\ACK} messages that arrive, triggered from retransmissions of the final
response.  When this state is entered, timer I is set to fire in T4
seconds for unreliable transports, and zero seconds for reliable
transports.  Once timer I fires, the server {\MUST} transition to the
``Terminated'' state.

Once the transaction is in the ''Terminated'' state, it {\MUST} be
destroyed.  As with client transactions, this is needed to ensure
reliability of the 2xx responses to {\INVITE}.

\subsubsection{Non-{\INVITE} Server Transaction}
\label{sec:transactions:server:noninv}

\txtpsfigsize{!}{!}{noninvite-server}{non-{\INVITE} server transaction}

The state machine for the non-{\INVITE} server transaction is shown in
Figure~\ref{fig:noninvite-server}. 

The state machine is initialized in the ``Trying'' state and is passed
a request other than {\INVITE} or {\ACK} when initialized.  This request
is passed up to the TU.  Once in the ``Trying'' state, any further
request retransmissions are discarded.  A request is a retransmission if
it matches the same server transaction, using the rules specified in
Section~\ref{sec:transactions:server:match}.

While in the ``Trying'' state, if the TU passes a provisional response
to the server transaction, the server transaction {\MUST} enter the
``Proceeding'' state.  The response {\MUST} be passed to the transport
layer for transmission.  Any further provisional responses that are
received from the TU while in the ``Proceeding'' state {\MUST} be passed
to the transport layer for transmission.  If a retransmission of the
request is received while in the ``Proceeding'' state, the most recently
sent provisional response {\MUST} be passed to the transport layer for
retransmission.  If the TU passes a final response (status codes
200-699) to the server while in the ``Proceeding'' state, the
transaction {\MUST} enter the ``Completed'' state, and the response
{\MUST} be passed to the transport layer for transmission.

When the server transaction enters the ``Completed'' state, it {\MUST}
set Timer J to fire in 64*T1 seconds for unreliable transports, and zero
seconds for reliable transports.  While in the ``Completed'' state, the
server transaction {\MUST} pass the final response to the transport
layer for retransmission whenever a retransmission of the request is
received.  Any other final responses passed by the TU to the server
transaction {\MUST} be discarded while in the ``Completed'' state.  The
server transaction remains in this state until Timer J fires, at which
point it {\MUST} transition to the ``Terminated'' state.

The server transaction {\MUST} be destroyed the instant it enters the
``Terminated'' state.

\subsubsection{Matching Requests to Server Transactions}
\label{sec:transactions:server:match}

When a request is received from the network by the server, it has to
be matched to an existing transaction. This is accomplished in the
following manner.

\begin{changebar}
The branch parameter in the topmost \header{Via} header field of the request is
examined.  If it is present and begins with the magic cookie
``z9hG4bK'', the request was generated by a client transaction compliant
to this specification.  Therefore, the branch parameter will be unique
across all transactions sent by that client.  The request matches a
transaction if the branch parameter in the request is equal to the one
in the top \header{Via} header field of the request that created the
transaction, the \header{sent-by} value in the top \header{Via} of the request is equal to the one in the request that created the transaction, and in the case of a {\CANCEL} request, the method of the
request that created the transaction was also {\CANCEL}.  This matching
rule applies to both {\INVITE} and non-{\INVITE} transactions alike.

\motivation{The \header{sent-by} value is used as part of the matching
process because there could be accidental or malicious duplication of
branch parameters from different clients.}
\end{changebar}

If the branch parameter in the top \header{Via} header field is not present,
or does not contain the magic cookie, the following procedures are
used. These exist to handle backwards compatibility with RFC~2543
compliant implementations.

\begin{changebar}
The {\INVITE} request matches a transaction if the \header{Request-URI},
\header{To} tag, \header{From} tag, \header{Call-ID}, \header{CSeq}, and top
\header{Via} header field match those of the {\INVITE} request which created
the transaction.  In this case, the {\INVITE} is a retransmission of the
original one that created the transaction.  The {\ACK} request matches a
transaction if the \header{Request-URI}, \header{From} tag,
\header{Call-ID}, \header{CSeq} number (not the method), and top
\header{Via} header field match those of the {\INVITE} request which created
the transaction, and the \header{To} tag of the {\ACK} matches the
\header{To} tag of the response sent by the server transaction.  Matching is done based on the matching rules
defined for each of those header fields. The usage of the tag in the
\header{To} header field helps disambiguate {\ACK} for 2xx from {\ACK} for
other responses at a proxy, which may have forwarded both responses
(which can occur in unusual conditions).  An {\ACK} request that matches
an {\INVITE} transaction matched by a previous {\ACK} is considered a
retransmission of that previous {\ACK}. 

For all other request methods, a request is matched to a transaction if
the \header{Request-URI}, \header{To} tag, \header{From} tag, \header{Call-ID}
\header{Cseq} (including the method), and top \header{Via} header field
match those of the request that created the transaction.  Matching is
done based on the matching rules defined for each of those header fields. 
When a non-{\INVITE} request matches an existing transaction, it is a
retransmission of the request that created that transaction. 
\end{changebar}

Because the matching rules include the \header{Request-URI}, the server
cannot match a response to a transaction.  When the TU passes a response
to the server transaction, it must pass it to the specific server
transaction for which the response is targeted. 

\subsubsection{Handling Transport Errors}
\label{sec:transactions:server:error}

When the server transaction sends a response to the transport layer to
be sent, the following procedures are followed if the transport layer
indicates a failure.

First, the procedures in~\citenorm{draft-ietf-sip-srv} are followed, which
attempt to deliver the response to a backup.  If those should all fail,
\begin{changebar} based on the definition of failure in~\citenorm{draft-ietf-sip-srv}, \end{changebar} the server transaction {\SHOULD} inform the TU that a failure 
has occurred, and {\SHOULD} transition to the terminated state.

