When a client wishes to send a request, the client either sends it to a
locally configured SIP proxy server, the so-called {\em outbound proxy},
independent of the \header{Request-URI}, or, if none is configured,
sends it to the IP address and port corresponding to the
\header{Request-URI}.  The outbound proxy can be configured by any
mechanism, including DHCP \cite{draft-ietf-sip-dhcp}.

We refer to the outbound proxy or \header{Request-URI} as the
\emph{destination}. The destination is identified by a network address,
transport protocol and port number. These parameters can be either
contained in the destination specification itself, can be looked up
indirectly via DNS or can default to a certain value.

If the \header{Request-URI} is used, the network address is the
\header{maddr} parameter if it exists and the \header{host} element if
not.  The transport protocol is the \header{transport} parameter; the
port number is the \header{port} element. 

Clients {\MUST} re-run the above selection algorithm, re-drawing any
random numbers involved, once per transaction rather than for each
request, i.e., requests within the same transaction {\MUST} be sent to
the same network address.  Thus, the same address is used for the
request, any retransmissions, any associated {\CANCEL} requests and
{\ACK} requests for non-2xx responses.  However, {\ACK}s for 2xx
responses use another iteration of the selection algorithm.  (Indeed, in
many cases, they may have different request URIs.)

A stateless proxy can accomplish this, for example, by using the modulo
$N$ of a hash of the \header{Call-ID} value or some other combination of
transaction-identifying headers as the uniform random number described
in the weighting algorithm of RFC 2782 \cite{rfc2782}.  Here, $N$ is the
sum of weights within the priority class.

The goal of the lookup algorithm is to obtain an ordered list of network
addresses, transport protocols and port numbers.  Once the client has
obtained such an ordered list, it tries each server in turn, until a
server responds.  If a server in the list cannot be reached, as
described in the next paragraph, the client moves to the next address in
the list, until the list is exhausted.  If the list is exhausted, then
the client gives up.  We describe three methods to obtain such a list,
depending on the parameters of the destination.  For each
\header{Request-URI} or other server specification, the client uses
exactly ONE of these methods. 

Message length or other request properties do not influence the server
selection. 

A client {\SHOULD} detect if the server is not reachable by timeout or a
network error indication, such as ICMP ``destination unreachable''
messages.  For socket-based programs, such ICMP messages are reflected
in the return value of function calls.  For TCP, {\tt connect()} returns
{\tt ECONNREFUSED} if the client could not connect to a server at that
address.  For UDP, the socket needs to be bound to the destination
address using {\tt connect()} rather than use {\tt sendto()} or similar. 
For a connected socket, a second {\tt write()} or {\tt send()} fails
with {\tt ECONNREFUSED} if the first message yielded an ICMP error
response.

\subsection{Numeric Destination Address}

If the destination address is a numeric IP address, the client
contacts the server at the given address and the port number specified
in the SIP-URI or, if not specified, the default port (5060).  

If the destination specifies a protocol, the ordered lists contains only
that protocol. Otherwise, the ordered lists contains all protocols
supported by the client, with UDP listed first, if applicable, and other
protocols listed in an implementation-defined order.

\subsection{No Port Number or Port 5060}

If the destination is a host name and it specifies no port number or
port number 5060, DNS SRV records are retrieved according to RFC 2782
\cite{rfc2782}.  The service identifier for DNS SRV records is
``\_sip''.  If the destination specifies the transport protocol, only
records for that protocol are retrieved.  (If the client does not
support the protocol specified, the client lookup fails.) If the
destination does not specify the protocol, the client retrieves records
for all transport protocols it supports.  The results of all queries are
merged and then sorted according to priority, independent of the
transport protocol.  If this list is empty, follow the procedure in the
next section.

Note that the behavior above differs slightly from that described in RFC
2782. There, A records are consulted if the query for one transport
protocol fails; here, we only abandon the SRV lookup if none of the
transport protocols supported by the client yield an answer. 

Then, servers are contacted as specified in the ``Usage rules'' section
of RFC 2782 \cite{rfc2782}, until either a server responds or all
servers have been tried.

Clients {\MUSTNOT} cache query results except according to the rules in
RFC 1035 \cite{rfc1035}.

\subsection{Port Number Other Than 5060 or No SRV Records}

If the destination specifies a domain name and a port number other than
5060 or if there are no suitable SRV records, the client queries the DNS
server for address records for the destination address.  Address records
include A RR's, AAAA RR's, or other similar records, chosen according to
the client's network protocol capabilities. 

The DNS address records are kept sorted in the order returned by the DNS
server.

Clients {\MUSTNOT} cache query results except according to the rules in
RFC 1035 \cite{rfc1035}.
