Internet Engineering Task Force                                   SIP WG
Internet Draft                                     Schulzrinne/Rosenberg
draft-ietf-sip-srv-01.txt                        Columbia U./dynamicsoft
October 6, 2000
January 2000 15, 2001
Expires: June 2001

        SIP: Session Initiation Protocol -- Locating SIP Servers


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at

   To view the list Internet-Draft Shadow Directories, see


   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.

1 Introduction

   This document updates Sections 1.3 and 1.4.2 and supercedes supersedes Appendix
   D of RFC 2543 [1]. Inter alia, it defines the term outbound proxy and
   replaces references to the obsoleted RFC 2052 with current references
   to RFC 2782.

1.1 Terminology

   In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
   "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for compliant SIP implementations.

1.2 Definitions

        Outbound proxy: A proxy that is located near the originator of
             requests. It receives all outgoing requests from a
             particular UAC, including those requests whose Request-URLs
             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. Request-URI. (All other proxy
             servers are simply referred as proxies, not inbound

2 Locating a SIP Server

   When a client wishes to send a request, the client either sends it to
   a locally configured SIP proxy server, the so-called outbound proxy ,
   independent of the Request-URI, or sends it to the IP address and
   port corresponding to the Request-URI. The outbound proxy can be
   configured by any mechanism, including DHCP [3]. [3] and can be specified
   either as a set of parameters such as network address or host name,
   protocol port and transport protocol, or as a SIP URI.

   If the 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


   Clients MUST determine the destination address once per transaction
   rather than for each step, unless stated otherwise, request, i.e., requests within the client SHOULD try same
   transaction MUST be sent to
   contact a server at the port number listed in the Request-URI.  If no
   port number is present in the Request-URI, the client uses port 5060.
   If same network address. A stateless
   proxy can accomplish this, for example, by using the Request-URI specifies modulo N of a protocol,
   hash of the client contacts Call-ID value or some other combination of transaction-
   identifying headers as the
   server using that protocol. If no protocol is specified, uniform random number described in the client
   tries UDP (if UDP
   weighting algorithm of RFC 2782. Here, N is supported). If the attempt fails with an ICMP
   error sum of "destination unreachable", code "port unreachable" or
   "protocol unreachable" or a time out, or if weights within
   the client doesn't
   support UDP but supports other protocols, it tries those protocols in
   some unspecified order. priority class.

   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,
   programs:  For TCP, connect() for TCP returns 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 connect() rather
   than sendto() or similar so that a second write() or send() fails
   with ECONNREFUSED if there is no server listening.) 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

   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

   The service identifier for DNS SRV records [4]

   If the client is "_sip".

        1. configured with the address of an outbound proxy,
   the parameters of the outbound proxy, including transport protocol
   and port, become the destination used below.

   If there is no outbound proxy, the maddr SIP URI parameter exists, it becomes destination is the Request-URI.
   The destination address used below; is the maddr parameter if not, it exists and the
   host element in
             the Request-URI if not. The transport protocol is the destination address.

        2. transport

   The service identifier for DNS SRV records [4] is "_sip".

        1.   If the destination address is an a numeric IP address, the
             client contacts the server at the given address and the
             port number specified in the Request-URI SIP-URI or, if none is not specified,
             the default port and ignores the remaining

        3.   The Request-URI is examined. (5060).

             If it contains no port number
             or port 5060, the transport parameter is inspected:

             1.   There are three cases: the Request-URI does not
                  specify a transport protocol, it destination specifies a client-
                  supported transport protocol, the client
             contacts the server using that protocol. If no protocol is
             specified, the client first tries UDP. If attempt fails, or
             if the client does not support UDP but supports other
             protocols, it tries those protocols in some
             implementation-defined order.

             The client then skips the remaining steps.

        2.   If the destination specifies a no port number or port number
             5060, the transport protocol that is not supported by determines the client. We
                  discuss these cases below in turn. use of one of
             the following three rules:

             - If the Request-URI destination does not specify a transport protocol,
               DNS SRV records are retrieved according to RFC 2782 [4].
               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 [4] is used to
               select servers in order. Server selection across requests
               is independent of previous choices, except as noted below above
               for stateless proxies. Message length or other request
               properties do not influence the server selection. 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

             - If the Request-URI specifies a transport protocol is specified and
                  the transport this 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 Request-URI. SIP-URI.

             - If the Request-URI specifies a transport protocol that specified is not supported by
               the client, the client gives up.

             If there are no SRV records, the Request-URI contains next step applies.

        3.   If the destination specifies 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

             If the DNS server returns no address records, the client
             gives up.

   Within a transaction, a stateless proxy MUST always select the same
   destination within the set of hosts with If there are address records, the same priority. This can
   be accomplished, for example, by using the modulo N of a hash of the
   Call-ID value or some other combination of transaction-identifying
   headers rules as the uniform random number described
             in the weighting
   algorithm of RFC 2782. Here, N is the sum of weights within the
   priority class.

   A client MAY step 2 apply.

   Clients MUSTNOT 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 except according to the rules in RFC1035
   RFC 1035 [5].

   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 Request-URI.

        A proxy is free to modify the Request-URI to any value
        desired, but the DNS lookups are usually based on the
        Request-URI obtained from a location server.

        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.

3 Security Considerations

   The security considerations in RFC 2543 [1] apply.

4 Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   electronic mail:

   Jonathan Rosenberg
   72 Eagle Rock Ave
   East Hanover, NJ 07936
   electronic mail:

5 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [3] G. Nair and H. Schulzrinne, "DHCP option for SIP servers,"
   Internet Draft, Internet Engineering Task Force, Apr. 2000.  Work in

   [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
   the location of services (DNS SRV)," Request for Comments 2782,
   Internet Engineering Task Force, Feb. 2000.

   [5] P. V. Mockapetris, "Domain names - implementation and
   specification," Request for Comments 1035, Internet Engineering Task
   Force, Nov. 1987.

   Full Copyright Statement

   Copyright (c) The Internet Society (2000). (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an