\section{Transport}
\label{sec:transport}

The transport layer is responsible for the actual transmission of
requests and responses over network transports.  This includes
determination of the connection to use for a request or response in the
case of connection-oriented transports.

The transport layer is responsible for managing persistent connections
for transport protocols like TCP and SCTP, or TLS over those, including
ones opened to the transport layer.  This includes connections opened by
the client or server transports, so that connections are shared between
client and server transport functions.  These connections are indexed by
the tuple formed from the address, port, and transport protocol at the
far end of the connection.  When a connection is opened by the transport
layer, this index is set to the destination IP, port and transport. 
When the connection is accepted by the transport layer, this index is
set to the source IP address, port number, and transport. 
\begin{changebar} Note that, because the source port is often ephemeral,
but it cannot be known whether it is ephemeral or selected through
procedures in~\citenorm{draft-ietf-sip-srv}, \end{changebar} connections
accepted by the transport layer will frequently not be reused.  The
result is that two proxies in a ``peering'' relationship using a
connection-oriented transport frequently will have two connections in
use, one for transactions initiated in each direction. 

It is {\RECOMMENDED} that connections be kept open for some
implementation-defined duration after the last message was sent or
received over that connection.  This duration {\SHOULD} at least equal
the longest amount of time the element would need in order to bring a
transaction from instantiation to the terminated state.  This is to make
it likely that transactions complete over the same connection on which
they are initiated (for example, request, response, and in the case of
{\INVITE}, {\ACK} for non-2xx responses).  \begin{changebar} This
usually means at least 64*T1 (see 
Section~\ref{sec:transactions:client:invite:overview} for a definition of T1). 
However, it could be larger in an element that has a TU using a large
value for timer C (bullet~\ref{sec:proxy-request-processing:timerc} of
Section~\ref{sec:proxy-request-forwarding}), for example. 
\end{changebar}

All SIP elements {\MUST} implement UDP and TCP.  SIP elements {\MAY}
implement other protocols.

\motivation{Making TCP mandatory for the UA is a substantial change from
RFC~2543.  It has arisen out of the need to handle larger messages,
which {\MUST} use TCP, as discussed below.  Thus, even if an element
never sends large messages, it may receive one and needs to be able to
handle them.}

\subsection{Clients}
\label{sec:transport:clients}

\subsubsection{Sending Requests}
\label{sec:transport:clients:sending}

The client side of the transport layer is responsible for sending the 
request and receiving responses. The user of the transport layer passes 
the client transport the request, an IP address, port, transport, and 
possibly TTL for multicast destinations.

\begin{changebar}
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request {\MUST} be sent
using TCP.  This prevents fragmentation of messages over UDP and 
provides congestion control for larger messages.  However,
implementations {\MUST} be able to handle messages up to the maximum
datagram packet size.  For UDP, this size is 65,535 bytes, including
IP and UDP headers.

\motivation{The 200 byte ``buffer'' between the message size and the MTU
accommodates the fact that the response in SIP can be larger than the
request.  This happens due to the addition of \header{Record-Route}
header field values to the responses to {\INVITE}, for example.  With
the extra buffer, the response can be about 170 bytes larger than the
request, and still not be fragmented on IPv4 (about 30 bytes is
consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU
is not known, based on the assumption of a 1500 byte Ethernet MTU.}
\end{changebar}

\begin{changebar}
If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over UDP,
if the attempt to establish the connection generates either an ICMP
Protocol Not Supported, or results in a TCP reset, the element
{\SHOULD} retry the request, using UDP. This is only to provide
backwards compatibility with RFC~2543 compliant implementations that
do not support UDP. It is anticipated that this behavior will be
deprecated in a future revision of this specification.
\end{changebar}

\begin{changebar}
A client that sends a request to a multicast address {\MUST} add the
``\header{maddr}'' parameter to its \header{Via} header field value
containing the destination multicast address, and for IPv4, {\SHOULD}
add the ``\header{ttl}'' parameter with a value of 1. Usage of IPv6
multicast is not defined in this specification, and will be a subject
of future standardization when the need arises.

These rules result in a purposeful limitation of multicast in SIP.
Its primary function is to provide an ``single-hop-discovery-like'' service,
delivering a request to a group of homogeneous servers, where it
is only required to process the response from any one of them. 
This functionality is most useful for registrations.
In fact, based on the transaction processing rules in 
Section~\ref{sec:transactions:client:match}, the client transaction will
accept the first response, and view any others as retransmissions
because they all contain the same \header{Via} branch identifier.
\end{changebar}

Before a request is sent, the client transport {\MUST} insert a value of
the ''\header{sent-by}'' field into the \header{Via} header field.  This field contains an
IP address or host name, and port.  The usage of an FQDN is
{\RECOMMENDED}.  This field is used for sending responses under certain
conditions, described below. \begin{changebar} If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. \end{changebar}

For reliable transports, the response is normally sent on the connection
on which the request was received.  Therefore, the client transport {\MUST} be
prepared to receive the response on the same connection used to send the
request.  Under error conditions, the server may attempt to open a new
connection to send the response.  To handle this case, the transport
layer {\MUST} also be prepared to receive an incoming connection on the
source IP address from which the request was sent and port number in the
''\header{sent-by}'' field.  It also {\MUST} be prepared to receive incoming
connections on any address and port that would be selected by a server
based on the procedures described in Section 5 
of~\citenorm{draft-ietf-sip-srv}.

For unreliable unicast transports, the client transport {\MUST} be
prepared to receive responses on the source IP address from which the request
is sent (as responses are sent back to the source address) and the
port number in the ''\header{sent-by}'' field.  Furthermore, as with reliable
transports, in certain cases the response will be sent elsewhere.  The
client {\MUST} be prepared to receive responses on any address and port
that would be selected by a server based on the procedures described in
Section 5 of~\citenorm{draft-ietf-sip-srv}.

For multicast, the client transport {\MUST} be prepared to receive
responses on the same multicast group and port to which the request is sent
(that is, it needs to be a member of the multicast group it sent the
request to.)

If a request is destined to an IP address, port, and transport to which
an existing connection is open, it is {\RECOMMENDED} that this
connection be used to send the request, but another connection {\MAY} be
opened and used. 

If a request is sent using multicast, it is sent to the group address,
port, and TTL provided by the transport user.  If a request is sent
using unicast unreliable transports, it is sent to the IP address and
port provided by the transport user.

\subsubsection{Receiving Responses}
\label{sec:transport:clients:receiving}

When a response is received, the client transport examines the top
\header{Via} header field value.  If the value of the ''\header{sent-by}''
parameter in that
header field value does not correspond to a value that the client transport is
configured to insert into requests, the response {\MUST} be silently discarded.

If there are any client transactions in existence, the client transport
uses the matching procedures of Section~\ref{sec:transactions:client:match} 
to attempt to match the response to
an existing transaction.  If there is a match, the response {\MUST} be
passed to that transaction.  Otherwise, the response {\MUST} be passed
to the core (whether it be stateless proxy, stateful proxy, or UA) for
further processing.  \begin{changebar} Handling of these ``stray'' responses is dependent
on the core (a proxy will forward them, while a UA will discard, for example). \end{changebar}

\subsection{Servers}
\label{sec:transport:servers}

\subsubsection{Receiving Requests}
\label{sec:transport:servers:receiving}

\begin{changebar}
A server {\SHOULD} be prepared to received requests on any IP address,
port and transport combination that can be the result of a DNS lookup
on a SIP or SIPS URI~\citenorm{draft-ietf-sip-srv} that is handed out for the
purposes of communicating with that server. In this context, ``handing
out'' includes placing a URI in a \header{Contact} header field in a
{\REGISTER} request or a any redirect response, or in a
\header{Record-Route} header field in a request or response. A URI can
also be ``handed out'' by placing it on a web page or business
card. It is also {\RECOMMENDED} that a server listen for requests on
the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on
all public interfaces. The typical exception would be private
networks, or when multiple server instances are running on the same
host. For any port and interface that a server listens on for UDP, it
{\MUST} listen on that same port and interface for TCP. This is
because a message may need to be sent using TCP, rather than UDP, if
it is too large. As a result, the converse is not true. A server need
not listen for UDP on a particular address and port just because it is
listening on that same address and port for TCP. There may, of course,
be other reasons why a server needs to listen for UDP on a particular
address and port.
\end{changebar}

When the server transport receives a request over any transport, it
{\MUST} examine the value of the ''\header{sent-by}'' parameter in the top
\header{Via} header field value.  If the host portion of the ''\header{sent-by}'' 
parameter
contains a domain name, or if it contains an IP address that differs
from the packet source address, the server {\MUST} add a
``\header{received}'' parameter to that \header{Via} header field value.  This
parameter {\MUST} contain the source address from which the packet was
received.  This is to assist the server transport layer in sending
the response, since it must be sent to the source IP address from which the
request came.

Consider a request received by the server transport which looks like, 
in part:

\begin{verbatim}
  INVITE sip:bob@Biloxi.com SIP/2.0
  Via: SIP/2.0/UDP bobspc.biloxi.com:5060
\end{verbatim}

The request is received with a source IP address of 192.0.2.4.  Before
passing the request up, the transport adds a ''\header{received}'' parameter, so
that the request would look like, in part:

\begin{verbatim}
  INVITE sip:bob@Biloxi.com SIP/2.0
  Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
\end{verbatim}

Next, the server transport attempts to match the request to a server
transaction.  It does so using the matching rules described 
in Section~\ref{sec:transactions:server:match}.
If a matching server transaction
is found, the request is passed to that transaction for processing.  If
no match is found, the request is passed to the core, which may decide
to construct a new server transaction for that request.  Note that when
a UAS core sends a 2xx response to {\INVITE}, the server transaction is
destroyed.  This means that when the {\ACK} arrives, there will be no
matching server transaction, and based on this rule, the {\ACK} is
passed to the UAS core, where it is processed. 

\subsubsection{Sending Responses}
\label{sec:transport:servers:sending}

The server transport uses the value of the top \header{Via} 
header field in order to
determine where to send a response.  It {\MUST} follow the following
process:

\begin{itemize}

\item If the ``\header{sent-protocol}'' is a reliable transport protocol
such as TCP or SCTP, or TLS over those, the response {\MUST} be sent using the
existing connection to the source of the original request that created
the transaction, if that connection is still open.  This requires
the server transport to maintain an association between server
transactions and transport connections.  \begin{changebar} If that connection is no longer
open, the server {\SHOULD} open a connection to the IP address in the
''\header{received}'' parameter, if present, using the port in the
''\header{sent-by}'' value, or the default port for that transport, if no
port is specified.  \end{changebar} If that
connection attempt fails, the server {\SHOULD} use the procedures
in~\citenorm{draft-ietf-sip-srv} for servers in order to determine the IP
address and port to open the connection and send the response to. 

\item Otherwise, if the \header{Via} header field value contains a
``\header{maddr}'' parameter, 
\begin{changebar}
the response {\MUST} be forwarded
\end{changebar}
to the address listed
there, using the port indicated in ``\header{sent-by}'', or port 5060 if
none is present.  If the address is a multicast address, the response
{\SHOULD} be sent using the TTL indicated in the ``\header{ttl}''
parameter, or with a TTL of 1 if that parameter is not present. 

\item Otherwise (for unreliable unicast transports), if the top
\header{Via} has a ''\header{received}'' parameter, 
\begin{changebar}
the response {\MUST} be sent
\end{changebar}
to the
address in the ``\header{received}'' parameter, using the port indicated
in the ``\header{sent-by}'' value, or using port 5060 if none is
specified explicitly.  \begin{changebar} If this fails, for example, elicits an ICMP ``port
unreachable'' response, the procedures of Section~5 of~\citenorm{draft-ietf-sip-srv} {\SHOULD} be used to determine where to send the response. \end{changebar}

\item Otherwise, if it is not receiver-tagged, 
\begin{changebar}
the response {\MUST} be sent
\end{changebar}
to the
address indicated by the ``\header{sent-by}'' value, using the
procedures in Section~5 of~\citenorm{draft-ietf-sip-srv}.

\end{itemize}

\subsection{Framing}

In the case of message-oriented transports (such as UDP), if the
message has a \header{Content-Length} header field, the message body is
assumed to contain that many bytes. If there are additional bytes in
the transport packet beyond the end of the body, they {\MUST} be
discarded. If the transport packet ends before the end of the message body,
this is considered an error. If the message is a response, it {\MUST}
be discarded. If the message is a request, the element {\SHOULD} generate a 
\begin{changebar}
400 (Bad Request) response. 
\end{changebar}
If the message has no \header{Content-Length} header field,
the message body is assumed to end at the end of the transport packet.

In the case of stream-oriented transports such as TCP, the
\header{Content-Length} header field indicates the size of the body. The
\header{Content-Length} header field {\MUST} be used with stream oriented
transports. 

\subsection{Error Handling}
\label{sec:transport:error}

Error handling is independent of whether the message was a request or 
response.

If the transport user asks for a message to be sent over an unreliable 
transport, and the result is an ICMP error, the behavior depends on the 
type of ICMP error. Host, network, port or protocol unreachable 
errors, or parameter problem errors {\SHOULD} cause the transport layer 
to inform the transport user of a failure in sending. Source quench and 
TTL exceeded ICMP errors {\SHOULD} be ignored.

If the transport user asks for a request to be sent over a reliable 
transport, and the result is a connection failure, the transport layer 
{\SHOULD} inform the transport user of a failure in sending.
