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

\subsection{Multicast Unreliable Transport Protocols}
\label{sec:multicast_udp}

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

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
{\MUST} be returned to the address listed in the \header{maddr}
parameter of the \header{Via} header field.  (This parameter is
{\REQUIRED}.) Generally, this will be a multicast address.  Such
multicast responses 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}).

To avoid response implosion, servers {\MUSTNOT} answer multicast
requests with a status code other than 2xx, 401, 407, 484 or 6xx.  The
server delays its response by a random interval uniformly distributed
between zero and one second.  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, 401, 407 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{Reliable Transport Protocols}

A single reliable transport connection such as TCP 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.) The client {\SHOULD} keep the connection open at
least until the first final response arrives. 

The server {\SHOULDNOT} close the connection until it has sent its
final response (and possibly received the {\ACK}), 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. These
requests can be for the same transaction or call, or for totally
different transactions or calls. There is no requirement that a
transaction must complete before a new one is initiated on an existing
connection. As a result, a server {\MUST} support receiving a request
for a new transaction on an existing connection before the previous
transaction on the same connection has completed. 

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 Requests Other Than {\INVITE}}
\label{sec:r-non-invite}

\subsubsection{Unreliable Transport Protocols}

A SIP client using an unreliable transport protocol such as UDP
{\SHOULD} retransmit requests other than {\INVITE} or {\ACK} 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 reaches $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 500\,ms and 4\,s,
respectively.  Clients {\MAY} use larger values, but {\SHOULDNOT} use
smaller ones.  Servers retransmit the response upon receipt of a request
retransmission.  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 request
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. 

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 500~ms.  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.}

{\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}.

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.

\subsubsection{Reliable Transport Protocol}

Clients using a reliable transport protocol such as TCP, SCTP or TLS do
{\em not} need to retransmit requests, but {\MAY} give up after
receiving no response for an extended period of time.

\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{Unreliable Transport Protocols}
\label{sec:r-invite-udp}

A SIP client using an unreliable transport protocol {\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 seven request
packets. If no response (final or provisional) is
received after sending seven request packets, processing continues as
if a 481 response was received for that request (no {\ACK} is
generated, however), and a {\CANCEL} {\SHOULDNOT} be
sent.

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 until it reaches
$T2$ seconds.  Response retransmissions cease when an {\ACK} request
is received or the response has been transmitted seven times.  The
entity generating the {\ACK} (a UAC for 2xx responses, UAC or proxy
for non-2xx) retransmits the {\ACK} on receipt of a response
retransmission. The value of a final response is not changed by the
arrival of a {\BYE} or {\CANCEL} request.

Servers {\SHOULD} only send a single 401 or 407 status response upon
receiving a request that is not authenticated at either the SIP,
transport or network layer. (See Section~\ref{sec:security:dos})

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.

Fig.~\ref{fig:sip_invite-client} and \ref{fig:sip_invite-server} show
the client and server state diagram for {\INVITE} transactions.  The
``terminated'' event occurs if the server receives either a {\CANCEL} or
{\BYE} request.  Note that the state diagram only shows the behavior for
the {\INVITE} transaction; the responses for {\BYE} and {\CANCEL} are
not shown and follow the rules laid in Section~\ref{sec:r-non-invite}.

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

\txtpsfigsize{!}{0.5\textheight}{sip_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{Reliable Transport Protocol}
\label{sec:r-invite-tcp}

A user agent using a reliable transport protocol such as TCP, SCTP or
TLS {\MUSTNOT} retransmit requests, but uses the same algorithm as for
unreliable transport protocols (Section~\ref{sec:r-invite-udp}) to
retransmit responses until it receives an {\ACK}.  A client {\MAY} give
up on the request if there is no response within a client-defined
timeout interval.

\motivation{It is necessary to retransmit 2xx responses as their
reliability is assured end-to-end only.  If the chain of proxies has an
unreliable transport protocol 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{ICMP Handling}
\label{sec:icmp}

Handling of ICMP messages in the case of unreliable transport protocol
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.