\documentclass[11pt]{article}
\usepackage{times,graphics,ifthen,i-d,html,txtpsfig,tight}
\usepackage[dvips]{changebar}

\title{SIP: Session Initiation Protocol -- Locating SIP Servers}
\author{Schulzrinne/Rosenberg}
\shorttitle{SIP}
\filename{ietf-sip-srv-01}
\wg{SIP WG}
\expires{April 2001}
\address{Columbia U./dynamicsoft}
\pubdate{\today}
%\input{rfc}
\input{../defs}

\begin{document}
\maketitle

\begin{abstract}
This document describes how a SIP client locates a SIP server based on
the Request-URI or a preconfigured outbound proxy server. This document
updates the process described in RFC 2543.
\end{abstract}

\section{Introduction}
\label{sec:intro}

This document updates Sections 1.3 and 1.4.2 and supercedes Appendix D
of RFC 2543 \cite{rfc2543}. Inter alia, it defines the term outbound
proxy and replaces references to the obsoleted RFC 2052 with current
references to RFC 2782.

\subsection{Terminology}
\label{sec:terminology}

In this document, the key words ``{\MUST}'', ``{\MUSTNOT}'',
``{\REQUIRED}'', ``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'',
``{\SHOULDNOT}'', ``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}''
are to be interpreted as described in RFC 2119 \cite{rfc2119} and
indicate requirement levels for compliant SIP implementations.

\subsection{Definitions}
\label{sec:definitions}

\begin{description}

\item[Outbound proxy:] A {\em proxy} that is located near the originator
of requests.  It receives all outgoing requests {\bf from} a particular
UAC, including those requests whose \header{Request-URL}s identify a
host other than the outbound proxy.  The outbound proxy sends these
requests, after any local processing, to the address indicated in the
request-URI.  (All other proxy servers are simply referred as proxies,
not {\em inbound} proxies.)

\end{description}

\section{Locating a SIP Server}
\label{sec:server}

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

If the \header{Request-URI} is used, the client needs to determine the
protocol, port and IP address of a server to which to send the request. 
A client {\SHOULD} follow the steps below to obtain this information.

At each step, unless stated otherwise, the client {\SHOULD} try to
contact a server at the port number listed in the \header{Request-URI}. 
If no port number is present in the \header{Request-URI}, the client
uses port 5060.  If the \header{Request-URI} specifies a protocol, the
client contacts the server using that protocol.  If no protocol is
specified, the client tries UDP (if UDP is supported).  If the attempt
fails with an ICMP error of ``destination unreachable'', code ``port
unreachable'' or ``protocol unreachable'' or a time out, or if the
client doesn't support UDP but supports other protocols, it tries those
protocols in some unspecified order.

A client {\SHOULD} be able to interpret explicit network notifications
(such as ICMP messages) which indicate that a server is not reachable,
rather than relying solely on timeouts.  (For example, in socket-based
programs, {\tt connect()} for TCP 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 {\tt sendto()} or similar so that a second {\tt
write()} or {\tt send()} fails with {\tt ECONNREFUSED} if there is no
server listening.) If the client finds the server is not reachable at a
particular address, it {\SHOULD} behave as if it had received a
400-class error response to that request.

The client tries to find one or more addresses for the SIP server by
querying DNS.  If a step elicits no addresses, the client continues to
the next step.  However if a step elicits one or more addresses, but no
SIP server at any of those addresses responds, then the client concludes
the server is down and does not continue on to the next step. 

The service identifier for DNS SRV records \cite{rfc2782} is ``\_sip''. 

\begin{enumerate}
\item If the \header{maddr} SIP URI parameter exists, it becomes the
\emph{destination address} used below; if not, the \header{host} element
in the \header{Request-URI} is the destination address.

\item If the destination address is an IP address, the client contacts
the server at the given address and the port number specified in the
\header{Request-URI} or, if none is specified, the default port and
ignores the remaining steps.

\item The \header{Request-URI} is examined. If it contains no port
number or port 5060, the \header{transport} parameter is inspected:

\begin{enumerate}
\item There are three cases:  the \header{Request-URI} does not specify
a transport protocol, it specifies a client-supported transport
protocol, or it specifies a protocol that is not supported by the
client.  We discuss these cases below in turn.

If the \header{Request-URI} does not specify a transport protocol,
DNS SRV records are retrieved according to RFC 2782 \cite{rfc2782}.  The
results of the query or queries are merged and ordered based on
priority, keeping only records with transport protocols that the client
supports.  Then, the searching technique outlined in RFC 2782
\cite{rfc2782} is used to select servers in order.  Server selection
across requests is independent of previous choices, except as noted
below for stateless proxies.  The client attempts to contact each server
in the order listed, at the port number specified in the SRV record.  If
none of the servers can be contacted, the client gives up.  If there are
no SRV records (with any transport protocol), DNS address records are
used, as described below.

If the \header{Request-URI} specifies a transport protocol and the
transport protocol is supported by the client, the procedure in the
paragraph above is used, limited to DNS resource records with the
transport protocol specified in the \header{Request-URI}.

If the \header{Request-URI} specifies a transport protocol that is not
supported by the client, the client gives up.

\end{enumerate}

If the \header{Request-URI} contains a port number other than 5060 or if
there are no 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.  If the DNS server returns no address
records, the client gives up.

\end{enumerate}

\begin{changebar}
Transactions are distributed across SIP servers using the regular SRV
load balancing algorithm. Message length or other request properties do
not influence the server selection.

Within a SIP transaction, a SIP client {\MUST} always select the same
destination within the set of hosts with the same priority.  If $N$ is
the sum of the weights within the priority class, the client can, for
example, use the remainder of the hash of transaction-identifying values
divided by $N$ to identify a particular entry in the list of
highest-priority addresses.  This remainder is used as the uniform
random number described in the weighting algorithm of RFC 2782. 
\end{changebar}

A client {\MAY} cache the list of DNS query results if one of the
addresses was contacted successfully.  Request for the same transaction
{\SHOULD} be sent to the same network address.  Other requests from the
same client select a server from the list of addresses cached, using the
SRV load-balancing mechanism if applicable.  The client must invalidate
this list and retry the DNS query according to the rules in RFC1035
\cite{rfc1035}.

A client {\MAY} omit attempting to reach a server which it had
failed to reach for a previous request.

The results of the DNS lookup operation do not, in general, lead to a
modification of the \header{Request-URI}.  \motivation{A proxy is free
to modify the \header{Request-URI} to any value desired, but the DNS
lookups are usually based on the \header{Request-URI} obtained from a
location server.}

\motivation{If the DNS time-to-live value exceeds a few minutes, servers
generating a large number of requests are probably well advised to retry
failed servers every few minutes.}

\section{Security Considerations}

The security considerations in RFC 2543 \cite{rfc2543} apply.

\section{Authors' Addresses}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\begin{flushleft}
Jonathan Rosenberg\\
dynamicsoft\\
72 Eagle Rock Ave\\
East Hanover, NJ 07936\\
USA\\
electronic mail: {\sf jdrosen@dynamicsoft.com}
\end{flushleft}

\bibliographystyle{ieeetr}
\bibliography{string,i-d,rfc}

\input{../copyright}

\end{document}
