Internet Engineering Task Force SIP WG Internet Draft Schulzrinne/Rosenberg
draft-ietf-sip-srv-00.txtdraft-ietf-sip-srv-01.txt Columbia U./dynamicsoft October 6, 2000 Expires:January 200015, 2001 Expires: June 2001 SIP: Session Initiation Protocol -- Locating SIP Servers STATUS OF THIS MEMO 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 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. 1 Introduction This document updates Sections 1.3 and 1.4.2 and supercedessupersedes Appendix D of RFC 2543 . 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", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119  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 proxies.) 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 . 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 information. AtClients MUST determine the destination address once per transaction rather than for each step, unless stated otherwise,request, i.e., requests within the client SHOULD trysame 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. Ifsame network address. A stateless proxy can accomplish this, for example, by using the Request-URI specifiesmodulo N of a protocol,hash of the client contactsCall-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 UDPweighting algorithm of RFC 2782. Here, N is supported). Ifthe attempt fails with an ICMP errorsum of "destination unreachable", code "port unreachable" or "protocol unreachable" or a time out, or ifweights 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, insocket-based programs,programs: For TCP, connect() for TCPreturns 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 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 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 becomesdestination is the Request-URI. The destination address used below;is the maddr parameter if not,it exists and the host element in the Request-URIif not. The transport protocol is the destination address. 2.transport parameter. The service identifier for DNS SRV records  is "_sip". 1. If the destination address is ana numeric IP address, the client contacts the server at the given address and the port number specified in the Request-URISIP-URI or, if none isnot specified, the default port and ignores the remaining steps. 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, itdestination specifies a client- supported transportprotocol, 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 ano port number or port number 5060, the transport protocol that is not supported bydetermines the client. We discuss these cases below in turn.use of one of the following three rules: - If the Request-URIdestination does not specify a transport protocol, DNS SRV records are retrieved according to RFC 2782 . 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  is used to select servers in order. Server selection across requests is independent of previous choices, except as noted belowabove 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 below. - If the Request-URI specifiesa transport protocol is specified and the transportthis 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 atransport protocol thatspecified is not supported by the client, the client gives up. If there are no SRV records, the Request-URI containsnext 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 capabilities. 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 withIf 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 headersrules as the uniform random number describedin the weighting algorithm of RFC 2782. Here, N is the sum of weights within the priority class. A client MAYstep 2 apply. Clients MUSTNOT cache the list of DNSquery 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 queryexcept according to the rules in RFC1035RFC 1035 . 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  apply. 4 Authors' Addresses Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: email@example.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA electronic mail: firstname.lastname@example.org 5 Bibliography  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999.  S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997.  G. Nair and H. Schulzrinne, "DHCP option for SIP servers," Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in progress.  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.  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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.