draft-ietf-sip-srv-05.txt   draft-ietf-sip-srv-06.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg Internet Draft J.Rosenberg
dynamicsoft dynamicsoft
H.Schulzrinne H.Schulzrinne
Columbia U. Columbia U.
draft-ietf-sip-srv-05.txt draft-ietf-sip-srv-06.txt
February 21, 2002 February 27, 2002
Expires: August 2002 Expires: August 2002
SIP: Locating SIP Servers SIP: 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4.3 Details of RFC 2782 Process ......................... 11 4.3 Details of RFC 2782 Process ......................... 11
4.4 Consideration for Stateless Proxies ................. 11 4.4 Consideration for Stateless Proxies ................. 11
5 Server Usage ........................................ 12 5 Server Usage ........................................ 12
6 Constructing SIP URIs ............................... 13 6 Constructing SIP URIs ............................... 13
7 Security Considerations ............................. 14 7 Security Considerations ............................. 14
8 The Transport Determination Application ............. 15 8 The Transport Determination Application ............. 15
9 IANA Considerations ................................. 15 9 IANA Considerations ................................. 15
10 Acknowledgements .................................... 16 10 Acknowledgements .................................... 16
11 Author's Addresses .................................. 16 11 Author's Addresses .................................. 16
12 Normative References ................................ 16 12 Normative References ................................ 16
13 Non-Normative References ............................ 17 13 Informative References .............................. 17
1 Introduction 1 Introduction
(NOTE TO RFC EDITOR: Please replace all instances of RFC BBBB with (NOTE TO RFC EDITOR: Please replace all instances of RFC BBBB with
the RFC number for draft-ietf-sip-rfc2543bis.) the RFC number for draft-ietf-sip-rfc2543bis.)
The Session Initiation Protocol (SIP) (RFC BBBB [1]) is a client- The Session Initiation Protocol (SIP) (RFC BBBB [1]) is a client-
server protocol used for the initiation and management of server protocol used for the initiation and management of
communications sessions between users. SIP end systems are called communications sessions between users. SIP end systems are called
user agents, and intermediate elements are known as proxy servers. A user agents, and intermediate elements are known as proxy servers. A
skipping to change at page 7, line 34 skipping to change at page 7, line 34
4.1 Selecting a Transport Protocol 4.1 Selecting a Transport Protocol
First, the client selects a transport protocol. First, the client selects a transport protocol.
If the URI specifies a transport protocol in the transport parameter, If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used. that transport protocol SHOULD be used.
Otherwise, if no transport protocol is specified, but the TARGET is a Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI. Similarly, if no TARGET is specified, and the TARGET for a SIPS URI. Similarly, if no transport protocol is specified, and
is not numeric, but an explicit port is provided, the client SHOULD the TARGET is not numeric, but an explicit port is provided, the
use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is
the only mandatory transport in RFC 2543 [6], and thus the only one because UDP is the only mandatory transport in RFC 2543 [6], and thus
guaranteed to be interoperable for a SIP URI. It was also specified the only one guaranteed to be interoperable for a SIP URI. It was
as the default transport in RFC 2543 when no transport was present in also specified as the default transport in RFC 2543 when no transport
the SIP URI. However, another transport, such as TCP, MAY be used if was present in the SIP URI. However, another transport, such as TCP,
the guidelines of SIP mandate it for this particular request. That is MAY be used if the guidelines of SIP mandate it for this particular
the case, for example, for requests that exceed the path MTU. request. That is the case, for example, for requests that exceed the
path MTU.
Otherwise, if no transport protocol or port is specified, and the Otherwise, if no transport protocol or port is specified, and the
target is not a numeric IP address, the client SHOULD perform a NAPTR target is not a numeric IP address, the client SHOULD perform a NAPTR
query for the domain in the URI. The services relevant for the task query for the domain in the URI. The services relevant for the task
of transport protocol selection are those with NAPTR service fields of transport protocol selection are those with NAPTR service fields
with values "SIP+D2x" and "SIPS+D2X", where x is a letter that with values "SIP+D2x" and "SIPS+D2X", where x is a letter that
corresponds to a transport protocol supported by the domain. This corresponds to a transport protocol supported by the domain. This
specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We specification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We
also establish an IANA registry for NAPTR service name to transport also establish an IANA registry for NAPTR service name to transport
protocol mappings. protocol mappings.
skipping to change at page 9, line 13 skipping to change at page 9, line 14
If a SIP proxy, redirect server, or registrar is to be contacted If a SIP proxy, redirect server, or registrar is to be contacted
through the lookup of NAPTR records, there MUST be at least three through the lookup of NAPTR records, there MUST be at least three
records - one with a "SIP+D2T" service field, one with a "SIP+D2U" records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
service field, and one with a "SIPS+D2T" service field. The records service field, and one with a "SIPS+D2T" service field. The records
with SIPS as the protocol in the service field SHOULD be preferred with SIPS as the protocol in the service field SHOULD be preferred
(i.e., have a lower value of the order field) above records with SIP (i.e., have a lower value of the order field) above records with SIP
as the protocol in the service field. A record with a "SIPS+D2U" as the protocol in the service field. A record with a "SIPS+D2U"
service field SHOULD NOT be placed into the DNS, since it is not service field SHOULD NOT be placed into the DNS, since it is not
possible to use TLS over UDP. possible to use TLS over UDP.
The domain suffixes in the NAPTR replacement field SHOULD match the It is not necessary for the domain suffixes in the NAPTR replacement
domain of the original query. The reason s It is not necessary for field to match the domain of the original query (i.e., example.com
the domain suffixes in the NAPTR replacement field to match the above). However, for backwards compatibility with RFC 2543, a domain
domain of the original query (i.e., example.com above). However, for MUST maintain SRV records for the domain of the original query, even
backwards compatibility with RFC 2543, a domain MUST maintain SRV if the NAPTR record is in a different domain. As an example, even
records for the domain of the original query, even if the NAPTR though the SRV record for TCP is _sip._tcp.school.edu, there MUST
record is in a different domain. As an example, even though the SRV also be an SRV record at _sip._tcp.example.com.
record for TCP is _sip._tcp.school.edu, there MUST also be an SRV
record at _sip._tcp.example.com.
RFC 2543 will look up the SRV records for the domain RFC 2543 will look up the SRV records for the domain
directly. If these do not exist because the NAPTR directly. If these do not exist because the NAPTR
replacement points to a different domain, the client will replacement points to a different domain, the client will
fail. fail.
For NAPTR records with SIPS protocol fields, if the server is using a For NAPTR records with SIPS protocol fields, if the server is using a
site certificate, the domain name in the query and the domain name in site certificate, the domain name in the query and the domain name in
the replacement field MUST both be valid based on the site the replacement field MUST both be valid based on the site
certificate handed out by the server in the TLS exchange. Similarly, certificate handed out by the server in the TLS exchange. Similarly,
skipping to change at page 10, line 25 skipping to change at page 10, line 25
If TARGET is a numeric IP address, the client uses that address. If If TARGET is a numeric IP address, the client uses that address. If
the URI also contains a port, it uses that port. If no port is the URI also contains a port, it uses that port. If no port is
specified, it uses the default port for the particular transport specified, it uses the default port for the particular transport
protocol. protocol.
If the TARGET was not a numeric IP address, but a port is present in If the TARGET was not a numeric IP address, but a port is present in
the URI, the client performs an A or AAAA record lookup of the domain the URI, the client performs an A or AAAA record lookup of the domain
name. The result will be a list of IP addresses, each of which can be name. The result will be a list of IP addresses, each of which can be
contacted at the specific port from the URI and transport protocol contacted at the specific port from the URI and transport protocol
determined previously. The client SHOULD try the one of the records. determined previously. The client SHOULD try the first record. If an
If an attempt should fail, based on the definition of failure in attempt should fail, based on the definition of failure in Section
Section 4.3, another SHOULD be tried. 4.3, the next SHOULD be tried.
If the TARGET was not a numeric IP address, and no port was present If the TARGET was not a numeric IP address, and no port was present
in the URI, the client performs an SRV query on the records returned in the URI, the client performs an SRV query on the records returned
from the NAPTR processing of Section 4.1, if such processing was from the NAPTR processing of Section 4.1, if such processing was
performed. If it was not, because a transport was specified performed. If it was not, because a transport was specified
explicitly, the client performs an SRV query for that specific explicitly, the client performs an SRV query for that specific
transport, using the service identifier "_sips" for SIPS URIs. For a transport, using the service identifier "_sips" for SIPS URIs. For a
SIP URI, if the client wishes to use TLS, it also uses the service SIP URI, if the client wishes to use TLS, it also uses the service
identifier "_sips" for that specific transport, otherwise, it uses identifier "_sips" for that specific transport, otherwise, it uses
"_sip". The procedures of RFC 2782, as described in the Section "_sip". The procedures of RFC 2782, as described in the Section
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu email: schulzrinne@cs.columbia.edu
12 Normative References 12 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Oct. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2001. Work in progress. 2002. Work in progress.
[2] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying [2] 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.
[3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) [3] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
DNS resource record," Request for Comments 2915, Internet Engineering DNS resource record," Request for Comments 2915, Internet Engineering
Task Force, Sept. 2000. Task Force, Sept. 2000.
[4] S. Bradner, "Key words for use in RFCs to indicate requirement [4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments 2119, Internet Engineering Task Force, levels," Request for Comments 2119, Internet Engineering Task Force,
Mar. 1997. Mar. 1997.
[5] T. Narten and H. Alvestrand, "Guidelines for writing an IANA [5] T. Narten and H. Alvestrand, "Guidelines for writing an IANA
considerations section in RFCs," Request for Comments 2434, Internet considerations section in RFCs," Request for Comments 2434, Internet
Engineering Task Force, Oct. 1998. Engineering Task Force, Oct. 1998.
13 Non-Normative References 13 Informative References
[6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[7] M. Mealling, "Dynamic delegation discovery system (DDDS) part [7] M. Mealling, "Dynamic delegation discovery system (DDDS) part
one: The comprehensive DDDS standard," Internet Draft, Internet one: The comprehensive DDDS standard," Internet Draft, Internet
Engineering Task Force, Oct. 2001. Work in progress. Engineering Task Force, Feb. 2002. Work in progress.
[8] M. Mealling, "Dynamic delegation discovery system (DDDS) part [8] M. Mealling, "Dynamic delegation discovery system (DDDS) part
three: The DNS database," Internet Draft, Internet Engineering Task three: The DNS database," Internet Draft, Internet Engineering Task
Force, Oct. 2001. Work in progress. Force, Feb. 2002. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved. Copyright (c) The Internet Society (2002). 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
 End of changes. 

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