draft-ietf-sip-srv-00.txt   draft-ietf-sip-srv-01.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft Schulzrinne/Rosenberg Internet Draft Schulzrinne/Rosenberg
draft-ietf-sip-srv-00.txt Columbia U./dynamicsoft draft-ietf-sip-srv-01.txt Columbia U./dynamicsoft
October 6, 2000 January 15, 2001
Expires: January 2000 Expires: June 2001
SIP: Session Initiation Protocol -- Locating SIP Servers SIP: Session Initiation Protocol -- Locating SIP Servers
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes how a SIP client locates a SIP server based This document describes how a SIP client locates a SIP server based
on the Request-URI or a preconfigured outbound proxy server. This on the Request-URI or a preconfigured outbound proxy server. This
document updates the process described in RFC 2543. document updates the process described in RFC 2543.
1 Introduction 1 Introduction
This document updates Sections 1.3 and 1.4.2 and supercedes Appendix This document updates Sections 1.3 and 1.4.2 and supersedes Appendix
D of RFC 2543 [1]. Inter alia, it defines the term outbound proxy and D of RFC 2543 [1]. Inter alia, it defines the term outbound proxy and
replaces references to the obsoleted RFC 2052 with current references replaces references to the obsoleted RFC 2052 with current references
to RFC 2782. to RFC 2782.
1.1 Terminology 1.1 Terminology
In this document, the key words "MUST", "MUSTNOT", "REQUIRED", In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted as described in RFC 2119 [2] and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant SIP implementations.
1.2 Definitions 1.2 Definitions
Outbound proxy: A proxy that is located near the originator of Outbound proxy: A proxy that is located near the originator of
requests. It receives all outgoing requests from a requests. It receives all outgoing requests from a
particular UAC, including those requests whose Request-URLs particular UAC, including those requests whose Request-URLs
identify a host other than the outbound proxy. The outbound identify a host other than the outbound proxy. The outbound
proxy sends these requests, after any local processing, to proxy sends these requests, after any local processing, to
the address indicated in the request-URI. (All other proxy the address indicated in the Request-URI. (All other proxy
servers are simply referred as proxies, not inbound servers are simply referred as proxies, not inbound
proxies.) proxies.)
2 Locating a SIP Server 2 Locating a SIP Server
When a client wishes to send a request, the client either sends it to 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 , a locally configured SIP proxy server, the so-called outbound proxy ,
independent of the Request-URI, or sends it to the IP address and independent of the Request-URI, or sends it to the IP address and
port corresponding to the Request-URI. The outbound proxy can be port corresponding to the Request-URI. The outbound proxy can be
configured by any mechanism, including DHCP [3]. configured by any mechanism, including DHCP [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 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 protocol, port and IP address of a server to which to send the
request. A client SHOULD follow the steps below to obtain this request. A client SHOULD follow the steps below to obtain this
information. information.
At each step, unless stated otherwise, the client SHOULD try to Clients MUST determine the destination address once per transaction
contact a server at the port number listed in the Request-URI. If no rather than for each request, i.e., requests within the same
port number is present in the Request-URI, the client uses port 5060. transaction MUST be sent to the same network address. A stateless
If the Request-URI specifies a protocol, the client contacts the proxy can accomplish this, for example, by using the modulo N of a
server using that protocol. If no protocol is specified, the client hash of the Call-ID value or some other combination of transaction-
tries UDP (if UDP is supported). If the attempt fails with an ICMP identifying headers as the uniform random number described in the
error of "destination unreachable", code "port unreachable" or weighting algorithm of RFC 2782. Here, N is the sum of weights within
"protocol unreachable" or a time out, or if the client doesn't the priority class.
support UDP but supports other protocols, it tries those protocols in
some unspecified order.
A client SHOULD be able to interpret explicit network notifications A client SHOULD be able to interpret explicit network notifications
(such as ICMP messages) which indicate that a server is not (such as ICMP messages) which indicate that a server is not
reachable, rather than relying solely on timeouts. (For example, in reachable, rather than relying solely on timeouts. (For socket-based
socket-based programs, connect() for TCP returns ECONNREFUSED if the programs: For TCP, connect() returns ECONNREFUSED if the client
client could not connect to a server at that address. For UDP, the could not connect to a server at that address. For UDP, the socket
socket needs to be bound to the destination address using connect() needs to be bound to the destination address using connect() rather
rather than sendto() or similar so that a second write() or send() than sendto() or similar so that a second write() or send() fails
fails with ECONNREFUSED if there is no server listening.) If the with ECONNREFUSED if there is no server listening) If the client
client finds the server is not reachable at a particular address, it finds the server is not reachable at a particular address, it SHOULD
SHOULD behave as if it had received a 400-class error response to behave as if it had received a 400-class error response to that
that request. request.
The client tries to find one or more addresses for the SIP server by 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 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 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 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 concludes the server is down and does not continue on to the next
step. step.
If the client is 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 destination is the Request-URI.
The destination address is the maddr parameter if it exists and the
host element if not. The transport protocol is the transport
parameter.
The service identifier for DNS SRV records [4] is "_sip". The service identifier for DNS SRV records [4] is "_sip".
1. If the maddr SIP URI parameter exists, it becomes the 1. If the destination address is a numeric IP address, the
destination address used below; if not, the host element in client contacts the server at the given address and the
the Request-URI is the destination address. port number specified in the SIP-URI or, if not specified,
the default port (5060).
2. If the destination address is an IP address, the client If the destination specifies a protocol, the client
contacts the server at the given address and the port contacts the server using that protocol. If no protocol is
number specified in the Request-URI or, if none is specified, the client first tries UDP. If attempt fails, or
specified, the default port and ignores the remaining if the client does not support UDP but supports other
steps. protocols, it tries those protocols in some
implementation-defined order.
3. The Request-URI is examined. If it contains no port number The client then skips the remaining steps.
or port 5060, the transport parameter is inspected:
1. There are three cases: the Request-URI does not 2. If the destination specifies no port number or port number
specify a transport protocol, it specifies a client- 5060, the transport protocol determines the use of one of
supported transport protocol, or it specifies a the following three rules:
protocol that is not supported by the client. We
discuss these cases below in turn.
If the Request-URI does not specify a transport - If the destination does not specify a transport protocol,
protocol, DNS SRV records are retrieved according to DNS SRV records are retrieved according to RFC 2782 [4].
RFC 2782 [4]. The results of the query or queries are The results of the query or queries are merged and
merged and ordered based on priority, keeping only ordered based on priority, keeping only records with
records with transport protocols that the client transport protocols that the client supports. Then, the
supports. Then, the searching technique outlined in searching technique outlined in RFC 2782 [4] is used to
RFC 2782 [4] is used to select servers in order. select servers in order. Server selection across requests
Server selection across requests is independent of is independent of previous choices, except as noted above
previous choices, except as noted below for stateless for stateless proxies. Message length or other request
proxies. The client attempts to contact each server in properties do not influence the server selection. The
the order listed, at the port number specified in the client attempts to contact each server in the order
SRV record. If none of the servers can be contacted, listed, at the port number specified in the SRV record.
the client gives up. If there are no SRV records (with If none of the servers can be contacted, the client gives
any transport protocol), DNS address records are used, up. If there are no SRV records (with any transport
as described below. protocol), DNS address records are used, as described
below.
If the Request-URI specifies a transport protocol and - If a transport protocol is specified and this protocol is
the transport protocol is supported by the client, the supported by the client, the procedure in the paragraph
procedure in the paragraph above is used, limited to above is used, limited to DNS resource records with the
DNS resource records with the transport protocol transport protocol specified in the SIP-URI.
specified in the Request-URI.
If the Request-URI specifies a transport protocol that - If the transport protocol specified is not supported by
is not supported by the client, the client gives up. the client, the client gives up.
If the Request-URI contains a port number other than 5060 If there are no SRV records, the 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 or if there are no SRV records, the client queries the DNS
server for address records for the destination address. server for address records for the destination address.
Address records include A RR's, AAAA RR's, or other similar Address records include A RR's, AAAA RR's, or other similar
records, chosen according to the client's network protocol records, chosen according to the client's network protocol
capabilities. If the DNS server returns no address records, capabilities.
the client gives up.
Within a transaction, a stateless proxy MUST always select the same
destination within the set of hosts with 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 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 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 [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 If the DNS server returns no address records, the client
desired, but the DNS lookups are usually based on the gives up. If there are address records, the same rules as
Request-URI obtained from a location server. in step 2 apply.
If the DNS time-to-live value exceeds a few minutes, Clients MUSTNOT cache query results except according to the rules in
servers generating a large number of requests are probably RFC 1035 [5].
well advised to retry failed servers every few minutes.
3 Security Considerations 3 Security Considerations
The security considerations in RFC 2543 [1] apply. The security considerations in RFC 2543 [1] apply.
4 Authors' Addresses 4 Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
skipping to change at page 5, line 47 skipping to change at page 5, line 33
[4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments 2782, the location of services (DNS SRV)," Request for Comments 2782,
Internet Engineering Task Force, Feb. 2000. Internet Engineering Task Force, Feb. 2000.
[5] P. V. Mockapetris, "Domain names - implementation and [5] P. V. Mockapetris, "Domain names - implementation and
specification," Request for Comments 1035, Internet Engineering Task specification," Request for Comments 1035, Internet Engineering Task
Force, Nov. 1987. Force, Nov. 1987.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved. Copyright (c) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/