\section{Behavior of SIP Clients and Servers}
\label{sec:transport}

\subsection{General Remarks}

SIP is defined so it can use either UDP (unicast or multicast) or TCP as
a transport protocol; it provides its own reliability mechanism.

\subsubsection{Requests}

Servers discard isomorphic requests, but first retransmit the appropriate
response.  (SIP requests are said to be {\em idempotent}, i.e.,
receiving more than one copy of a request does not change the server
state.)

After receiving a {\CANCEL} request from an upstream client, a stateful
proxy server {\MAY} send a {\CANCEL} on all branches where it has not
yet received a final response.

When a user agent receives a request, it checks the \header{Call-ID}
against those of in-progress calls.  If the \header{Call-ID} was found,
it compares the tag value of \header{To} with the user's tag and rejects
the request if the two do not match.  If the \header{From} header,
including any tag value, matches the value for an existing call leg, the
server compares the \header{CSeq} header field value.  If less than or
equal to the current sequence number, the request is a retransmission. 
Otherwise, it is a new request.  If the \header{From} header does not
match an existing call leg, a new call leg is created.

If the \header{Call-ID} was not found, a new call leg is created, with
entries for the \header{To}, \header{From} and \header{Call-ID} headers. 
In this case, the \header{To} header field should not have contained a
tag.  The server returns a response containing the same \header{To}
value, but with a unique tag added.  The tag {\MAY} be omitted if the
\header{To} refers to a fully qualified host name.

\subsubsection{Responses}

A server {\MAY} issue one or more provisional responses at any time
before sending a final response.  If a stateful proxy, user agent
server, redirect server or registrar cannot respond to a request with a
final response within 200 ms, it {\MUST} issue a provisional (1xx)
response as soon as possible.  Stateless proxies {\MUSTNOT} issue
provisional responses on their own. 

Responses are mapped to requests by the matching \header{To},
\header{From}, \header{Call-ID}, \header{CSeq} headers and the
\header{branch} parameter of the first \header{Via} header.  Responses
terminate request retransmissions even if they have \header{Via} headers
that cause them to be delivered to an upstream client.

A stateful proxy may receive a response that it does not have state for,
that is, where it has no a record of an associated request.  If the
\header{Via} header field indicates that the upstream server used TCP,
the proxy actively opens a TCP connection to that address.  Thus,
proxies have to be prepared to receive responses on the incoming side of
passive TCP connections, even though most responses will arrive on the
incoming side of an active connection.  (An active connection is a TCP
connection initiated by the proxy, a passive connection is one accepted
by the proxy, but initiated by another entity.)

100 responses {\SHOULDNOT} be forwarded, other 1xx responses {\MAY} be
forwarded, possibly after the server eliminates responses with status
codes that had already been sent earlier.  2xx responses are forwarded
according to the \header{Via} header.  Once a stateful proxy has
received a 2xx response, it {\MUSTNOT} forward non-2xx final responses.
Responses with status 300 and higher are retransmitted by each stateful
proxy until the next upstream proxy sends an {\ACK} (see below for
timing details) or {\CANCEL}.

A stateful proxy {\SHOULD} maintain state for at least 32 seconds
after the receipt of the first definitive non-200 response, in order
to handle retransmissions of the response.

\motivation{The 32 second window is given by the maximum retransmission
duration of 200-class responses using the default timers, in case
the {\ACK} is lost somewhere on the way to the called user agent or
the next stateful proxy.}

\subsection{Source Addresses, Destination Addresses and Connections}

\subsubsection{Unicast UDP}

Responses are returned to the address listed in the \header{Via} header
field (Section~\ref{sec:Via}), {\em not} the source address of the
request.

\begin{changebar}
\motivation{Recall that responses are not generated by the
next-hop stateless server, but generated by either a proxy server or the
user agent server. Thus, the stateless proxy can only use the
\header{Via} header field to forward the response.}
\end{changebar}

\subsubsection{Multicast UDP}

Requests {\MAY} be multicast; multicast requests likely feature a
host-independent
\header{Request-URI}.
\begin{changebar}
This request {\SHOULD} be scoped to ensure it is not forwarded beyond
the boundaries of the administrative system. This {\MAY} be done with
either TTL or administrative scopes\cite{rfc2365}, depending on what
is implemented in the network. However, use of administrative scoping
is {\RECOMMENDED}.
\end{changebar}

A client receiving a multicast query does not have to check whether the
{\em host} part of the \header{Request-URI} matches its own host or
domain name.  If the request was received via multicast, the response is
also returned via multicast.  Responses to multicast requests are
multicast with the same TTL as the request, where the TTL is derived
from the \header{ttl} parameter in the \header{Via} header
(Section~\ref{sec:Via}).

\begin{changebar}
To avoid response implosion, servers {\MUSTNOT} answer multicast
requests with a status code other than 2xx or 6xx.  The server delays
its response by a random interval uniformly distributed between zero
and one second.
\end{changebar}
Servers {\MAY} suppress responses if they hear a
lower-numbered or 6xx response from another group member prior to
sending.  Servers do not respond to {\CANCEL} requests received via
multicast to avoid request implosion. A proxy or UAC {\SHOULD} send a
{\CANCEL} on receiving the first 2xx or 6xx response to a multicast
request.
\motivation{Server response suppression is a {\MAY} since it requires a
server to violate some basic message processing rules. Lets say A sends a
multicast request, and it is received by B,C, and D. B sends a 200
response. The topmost \header{Via} field in the response will contain
the address of A. C will also receive this response, and could use it
to suppress its own response. However, C would normally not examine
this response, as the topmost \header{Via} is not its own. Normally, a
response received with an incorrect topmost \header{Via} {\MUST} be
dropped, but not in this case. To distinguish this packet from a
misrouted or multicast looped packet is fairly complex, and for this
reason the procedure is a {\MAY}. The {\CANCEL}, instead, provides a
simpler and more standard way to perform response suppression. It is
for this reason that the use of {\CANCEL} here is a {\SHOULD}}

\subsection{TCP}

A single TCP connection can serve one or more SIP transactions.  A
transaction contains zero or more provisional responses followed by
one or more final responses. (Typically, transactions contain exactly
one final response, but there are exceptional circumstances, where, for
example, multiple 200 responses can be generated.)

\begin{changebar}
The client {\SHOULD} keep the connection open at least until the first
final response arrives.  If the client closes or resets the TCP
connection prior to receiving the first final response, the server
treats this action as equivalent to a {\CANCEL} request.

\motivation{This behavior makes it less likely that malfunctioning
clients cause a proxy server to keep connection state indefinitely.}
\end{changebar}

The server {\SHOULDNOT} close the TCP connection until it has sent its
final response, at which point it {\MAY} close the TCP connection if it
wishes to.  However, normally it is the client's responsibility to close
the connection. 

If the server leaves the connection open, and if the client so desires
it {\MAY} re-use the connection for further SIP requests or for requests
from the same family of protocols (such as HTTP or stream control
commands).

If a server needs to return a response to a client and no longer has a
connection open to that client, it {\MAY} open a connection to the
address listed in the \header{Via} header.  Thus, a proxy or user agent
{\MUST} be prepared to receive both requests and responses on a
``passive'' connection.

\subsection{Reliability for {\BYE}, {\CANCEL}, {\OPTIONS}, {\REGISTER}
Requests}
\label{sec:r-non-invite}

\subsubsection{UDP}
<<<<<<< transport.tex
=======
\begin{changebar}
A SIP client {\em using UDP} {\SHOULD} retransmit a {\BYE},
{\CANCEL}, {\OPTIONS}, or {\REGISTER} request with an exponential
backoff, starting at a $T1$ second interval, doubling the interval
for each packet, and capping off at a $T2$ second interval. This
means that after the first packet is sent, the second is sent $T1$
seconds later, the next $2*T1$ seconds after that, the next $4*T1$
seconds after that, and so on, until the interval hits
$T2$. Subsequent retransmissions are spaced by T2 seconds. If the
client receives a provisional response, it continues to retransmit
the request, but with an interval of $T2$ seconds. Retransmissions
cease when the client has sent a total of eleven packets, or
receives a definitive response. Default values for $T1$ and $T2$ are
500ms and 4s, respectively. Clients {\MAY} use larger values, but
{\SHOULDNOT} use smaller ones. After the server sends a final
response, it cannot be sure the client has received the response,
and thus {\SHOULD} cache the results for at least $10*T2$ seconds to
avoid having to, for example, contact the user or location server
again upon receiving a retransmission.

\motivation{Use of the exponential backoff is for congestion control
purposes. However, the back-off must cap off, since request retransmissions
are used to trigger response retransmissions at the server. Without a
cap, the loss of a single response could significantly increase
transaction latencies. 
>>>>>>> 1.24

<<<<<<< transport.tex
A SIP client {\em using UDP} {\SHOULD} retransmit a {\BYE}, {\CANCEL},
{\OPTIONS}, or {\REGISTER} request periodically with timer $T1$ until it
receives a response, or until it has reached a set limit on the number
of retransmissions.  If the response is provisional, the client
continues to retransmit the request, albeit less frequently, using timer
$T2$.  The default values of timer $T1$ and $T2$ are 1 and 5 seconds,
respectively.  The default retransmit limit is 20 times.  After the
server sends a final response, it cannot be sure the client has received
the response, and thus {\SHOULD} cache the results for at least 100
seconds to avoid having to, for example, contact the user or location
server again upon receiving a retransmission.

Each server in a proxy chain generates its own final response to a
{\CANCEL} request.  The server responds immediately upon receipt of the
{\CANCEL} request rather than waiting until it has received final
responses from the {\CANCEL} requests it generates.

{\BYE} and {\OPTIONS} final responses are generated by redirect and user
agent servers; {\REGISTER} final responses are generated by registrars. 
Note that in contrast to the reliability mechanism described in
Section~\ref{sec:r-invite}, responses to these requests are {\em not}
retransmitted and {\em not} acknowledged via {\ACK}.

\motivation{The value of the initial retransmission timer is smaller
than that that for TCP since it is expected that network paths suitable
for interactive communications have round-trip times smaller than 1
second.  To avoid flooding the network with packets every second even if
the destination network is unreachable, the retransmission count has to
be bounded.  Given that most transactions are expected to consist of one
request and a few responses, round-trip time estimation is not likely to
be very useful.  If RTT estimation is desired to more quickly discover a
missing final response, each request retransmission needs to be labeled
with its own \header{Timestamp} (Section~\ref{sec:Timestamp}), returned
in the response.  The server caches the result until it can be sure that
the client will not retransmit the same request again.}
=======
The value of the initial retransmission timer is smaller
than that that for TCP since it is expected that network paths suitable
for interactive communications have round-trip times smaller than 500ms.
For congestion control purposes, the retransmission count has to
be bounded.  Given that most transactions are expected to consist of one
request and a few responses, round-trip time estimation is not likely to
be very useful.  If RTT estimation is desired to more quickly discover a
missing final response, each request retransmission needs to be labeled
with its own \header{Timestamp} (Section~\ref{sec:Timestamp}), returned
in the response.  The server caches the result until it can be sure that
the client will not retransmit the same request again.}
\end{changebar}

Each server in a proxy chain generates its own final response to a
{\CANCEL} request.  The server responds immediately upon receipt of the
{\CANCEL} request rather than waiting until it has received final
responses from the {\CANCEL} requests it generates.

{\BYE} and {\OPTIONS} final responses are generated by redirect and user
agent servers; {\REGISTER} final responses are generated by registrars. 
Note that in contrast to the reliability mechanism described in
Section~\ref{sec:r-invite}, responses to these requests are {\em not}
retransmitted periodically and {\em not} acknowledged via {\ACK}.
>>>>>>> 1.24

\subsubsection{TCP}

Clients using TCP do {\em not} need to retransmit requests.

\subsection{Reliability for {\INVITE} Requests}
\label{sec:r-invite}

Special considerations apply for the {\INVITE} method. 

\begin{enumerate}
\item After receiving an invitation, considerable time can elapse before
the server can determine the outcome.  For example, if the called party
is ``rung'' or extensive searches are performed, delays between the
request and a definitive response can reach several tens of seconds.  If
either caller or callee are automated servers not directly controlled by
a human being, a call attempt could be unbounded in time.

\item If a telephony user interface is modeled or if we need to
interface to the PSTN, the caller's user interface will provide
``ringback'', a signal that the callee is being alerted.  (The status
response 180 (Ringing) {\MAY} be used to initiate ringback.) Once the
callee picks up, the caller needs to know so that it can enable the
voice path and stop ringback.  The callee's response to the invitation
could get lost.  Unless the response is transmitted reliably, the caller
will continue to hear ringback while the callee assumes that the call
exists.

\item The client has to be able to terminate an on-going request, e.g.,
because it is no longer willing to wait for the connection or search to
succeed.  The server will have to wait several retransmission intervals to
interpret the lack of request retransmissions as the end of a call.  If
the call succeeds shortly after the caller has given up, the callee will
``pick up the phone'' and not be ``connected''.

\end{enumerate}

\subsubsection{UDP}
\label{sec:r-invite-udp}

\begin{changebar}
For UDP, A SIP client {\SHOULD} retransmit a SIP {\INVITE} request
with an interval that starts at $T1$ seconds, and doubles after each packet
transmission. The client ceases retransmissions if it receives a
provisional or definitive response, or once it has sent a total of 7
request packets. 

A server which transmits a provisional response should retransmit it
upon reception of a duplicate request. A server which transmits a
final response should retransmit it with an interval that starts at
$T1$ seconds, and doubles for each subsequent
packet. Retransmissions cease when any one of the following occurs:

\begin{enumerate}
\item An {\ACK} request for the same transaction is received;
\item a {\BYE} request for the same call leg is received;
\item a {\CANCEL} request for the same call leg is received {\bf and}
the final response status was equal or greater to 300;
\item the response has been transmitted 7 times.
\end{enumerate}
\end{changebar}

Only the user agent client generates an {\ACK} for 2xx final responses, 
If the response contained a \header{Contact} header field, the {\ACK}
{\MAY} be sent to the address listed in that \header{Contact} header
field.  If the response did not contain a \header{Contact} header, the
client uses the same \header{To} header field and \header{Request-URI}
as for the {\INVITE} request and sends the {\ACK} to the same
destination as the original {\INVITE} request.  {\ACK}s for final
responses other than 2xx are sent to the same server that the original
request was sent to, using the same \header{Request-URI} as the original
request.  Note, however, that the \header{To} header field in the {\ACK}
is copied from the response being acknowledged, not the request, and
thus {\MAY} additionally contain the \header{tag} parameter.  Also note
than unlike 2xx final responses, a proxy generates an {\ACK} for non-2xx
final responses.

<<<<<<< transport.tex
The server retransmits the final response at intervals of $T4$ (default
value of $T4$ = 2 seconds) until one of the following conditions is
true:
\begin{enumerate}
\item An {\ACK} request for the same transaction is received;
\item a {\BYE} request for the same call leg is received;
\item a {\CANCEL} request for the same call leg is received {\bf and}
the final response status was equal or greater to 300;
\item the response has been retransmitted 10 times.
\end{enumerate}

=======
>>>>>>> 1.24
The {\ACK} request {\MUSTNOT} be acknowledged to prevent a
response-{\ACK} feedback loop.  Fig.~\ref{fig:invite-client} and
\ref{fig:invite-server} show the client and server state diagram for
invitations.

\txtpsfigsize{!}{0.5\textheight}{invite-client}{State transition
diagram of client for {\INVITE} method}

\txtpsfigsize{!}{0.5\textheight}{invite-server}{State transition
diagram of server for {\INVITE} method}

\motivation{The mechanism in Sec.~\ref{sec:r-non-invite} would not work
well for {\INVITE} because of the long delays between {\INVITE} and a
final response.  If the 200 response were to get lost, the callee would
believe the call to exist, but the voice path would be dead since the
caller does not know that the callee has picked up.  Thus, the {\INVITE}
retransmission interval would have to be on the order of a second or two
to limit the duration of this state confusion.  Retransmitting the
response with an exponential back-off helps ensure that the response
is received, without placing an undue burden on the network.}

\subsubsection{TCP}
\label{sec:r-invite-tcp}

A client using TCP {\MUSTNOT} retransmit requests, but uses the same
algorithm as for UDP (Section~\ref{sec:r-invite-udp}) to retransmit
responses until it receives an {\ACK}.

\motivation{It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only.  If the chain of proxies has a
UDP link in the middle, it could lose the response, with no possibility
of recovery.  For simplicity, we also retransmit non-2xx responses,
although that is not strictly necessary.}

\subsection{Reliability for {\ACK} Requests}
\label{sec:r-ACK}

The {\ACK} request does not generate responses.  It is only generated
when a response to an {\INVITE} request arrives (see
Section~\ref{sec:r-invite}).  This behavior is independent of the
transport protocol.  Note that the {\ACK} request {\MAY} take a
different path than the original {\INVITE} request, and {\MAY} even
cause a new TCP connection to be opened in order to send it.

\subsection{ICMP Handling}
\label{sec:icmp}
Handling of ICMP messages in the case of UDP messages is
straightforward. For requests, a host, network, port, or protocol
unreachable error {\SHOULD} be treated as if a 400-class response was
received. For responses, these errors {\SHOULD} cause the server to
cease retransmitting the response.

Source quench ICMP messages {\SHOULD} be ignored. TTL exceeded errors
{\SHOULD} be ignored. Parameter problem errors {\SHOULD} be treated as
if a 400-class response was received.

