Internet Engineering Task Force B. Campbell Internet-Draft dynamicsoft Expires: May 14, 2002 November 13, 2001 Resolution of e.164 numbers in SIP Applications draft-ietf-sipping-e164-00 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Campbell Expires May 14, 2002 [Page 1] Internet-Draft SIP e.164 Resolution November 2001 Abstract This document describes how SIP may use the DNS to resolve services associated with E.164 numbers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes since Previous Version . . . . . . . . . . . . . . . . 3 3. Scope of Document . . . . . . . . . . . . . . . . . . . . . . 3 4. E.164 Telephone Number usage in SIP . . . . . . . . . . . . . 3 5. User Agent Client . . . . . . . . . . . . . . . . . . . . . . 4 6. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. DNS Query results . . . . . . . . . . . . . . . . . . . . . . 5 9. Application Examples . . . . . . . . . . . . . . . . . . . . . 6 9.1 Egress Gateway Location . . . . . . . . . . . . . . . . . . . 6 9.2 Ingress Gateway Call Routing . . . . . . . . . . . . . . . . . 6 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 Campbell Expires May 14, 2002 [Page 2] Internet-Draft SIP e.164 Resolution November 2001 1. Introduction There are several situations where a SIP User Agent or Proxy[2] must resolve a destination for a telephone number. For example, a user might specify a tel URL[4]. Commonly a UA would resolve such a number by sending an INVITE to another pre-provisioned network element, which assumedly knows what to do with it. RFC 2916[1] describes a method of using DNS NAPTR[1] records to resolve resources that are associated with an e.164 number. There are several situations where this approach can be advantageous for a SIP UA or proxy. 2. Changes since Previous Version Changed document name to reflect status as a SIPPING work group item. Cleaned up normative language to indicate that, while enum usage itself is optional, an implementation choosing to use them must follow certain procedures. Removed open issue section. Updated references. Fixed incorrect reference to tel URLs occuring in contact header. Made several non-substantive changes to improve readability. 3. Scope of Document This document describes when a SIP user agent or proxy should use the method described in RFC 2916[1] to resolve E.164 telephone numbers. It does not describe the actual details of telephone number resolution, since they are well defined in RFC 2916[1] . Neither does it describe the provisioning of the telephone numbers in DNS in the first place. 4. E.164 Telephone Number usage in SIP Telephone numbers are commonly specified in SIP either through the use of a tel URL, or through the use of a SIP URL with a user parameter that has a value of "phone." For example: tel:+1234567890 sip:+1234567890@example.com;user=phone Campbell Expires May 14, 2002 [Page 3] Internet-Draft SIP e.164 Resolution November 2001 Both examples describe a globally-scoped telephone number (i.e. E.164 number). It is tempting to say that the tel URL and SIP URL in the examples refer to the same phone number, therefore should both be resolved using DNS. However, the SIP URL also contains a host part. In this case, the request destination should be determined from the host part of the URI. The decision of how to handle the telephone number should be delegated to that destination device. An important aspect of an E.164 number is that it is globally addressable. RFC 2916[1] specifies the use of the DNS domain of "e164.arpa" for globally addressable numbers. A SIP device MUST NOT use "e164.arpa" to resolve a locally scoped telephone number. The user agent MAY use other domains for the resolution of numbers in a local or private dial plan. RFC 2916[1] states that a prefix of "+" before the digit string designates the number as globally addressable. 5. User Agent Client If a UAC wishes to send an invite to an e.164 number in the form of a tel URL, or a sip URL where the domain portion designates the UAC in question, it SHOULD use DNS resolve the number. It MAY, however, choose some other method to resolve the URL, such as a location service, a local database, or some other method. If it chooses to use DNS for number resolution, it MUST follow the procedures described in RFC 2916.[1] It SHOULD NOT use a DNS query to resolve a number that was presented as part of a SIP URL, where the host portion designates some other entity. In this case it SHOULD send the request to the entity designated by the URL and allow that entity to resolve the number. A UAC that is configured to use a default outbound proxy SHOULD NOT attempt to resolve an e.164 number. It SHOULD instead delegate that responsibility to the proxy. 6. Proxy When a proxy receives a request with an E.164 number in the requestURI, it SHOULD use DNS to resolve the number. It MAY, however, use some other method depending on local policy. If it chooses to use DNS for number resolution, it MUST follow the procedures described in RFC 2916.[1] For example, a proxy or redirect server might choose to use DNS to find associated resources for all requests with an e.164 number in the requestURI, or it might choose to check with a Campbell Expires May 14, 2002 [Page 4] Internet-Draft SIP e.164 Resolution November 2001 location services first, and use DNS only when the location service had no contacts associated with the requestURI. If the e.164 number was received as part of a sip URL, and the domain portion does not refer to a domain owned by the proxy, it SHOULD NOT attempt to resolve the number and instead SHOULD forward the request to the network element designated by the URL. A proxy that is configured to use a default outbound proxy SHOULD NOT attempt to resolve an e.164 number. It SHOULD instead delegate that responsibility to the proxy. 7. PSTN Gateway A PSTN to SIP gateway MAY use DNS to find resources to which an incoming PSTN call should be routed, only if it can construct an e.164 number from dialed digits. Alternately, the gateway might refer the call to a proxy or redirect server by sending an INVITE request with the e.164 number in the requestURI. As before, if it chooses to use DNS for number resolution, it MUST follow the procedures described in RFC 2916.[1] A gateway might be able to construct the e.164 number from the dialed number in the case of a DID call, or from a post-dial digit string, or through some other method. However, it is not appropriate to use the "e164.arpa" domain to resolve resources for a locally scoped number, or number from a private dial plan. A gateway may use internal domains for that purpose. 8. DNS Query results RFC 2916[1] specifies that the NAPTR RR service field specifies the resolution protocol and resolution service. For sip and tel URIs, the service field SHOULD be "sip+E2U" and "tel+E2U" respectively The resulting URI MUST be resolved according to the normal SIP address resolution rules. A SIP application MUST ignore a resulting URI if the service field does not contain a service it understands. Since the only schema that are universally understood by SIP user agents are "sip" and "tel", URIs with service fields other than "sip+E2U" and "tel+E2U" SHOULD NOT be present in DNS for the purpose of being used by a SIP UA. The application MUST handle the NAPTR order and preference fields as specified in RFC 2916[1]. The final result of the ENUM resolution MUST be treated the same as the results from any other location service, that is, it should appear in the requestURI of the resulting SIP request. If the result Campbell Expires May 14, 2002 [Page 5] Internet-Draft SIP e.164 Resolution November 2001 is an e.164 number, the application SHOULD attempt to resolve the new number using DNS. If the result included no records that the application can use, the application MAY attempt to resolve the number using local methods. 9. Application Examples The following are some examples of applications that could be facilitated using DNS resolution of resources associated with e.164 telephone numbers: 9.1 Egress Gateway Location Associating resources with a number in DNS allows SIP to PSTN gateway selection to be determined by the owner of the number, instead of the originator of a call. This could be accomplished by associating the e.164 number with a SIP URL that pointed to the gateway or gateways of choice. 9.2 Ingress Gateway Call Routing A PSTN to SIP gateway (or an associated proxy) could determine the ultimate destination for an inbound call by querying DNS and presenting an e.164 number constructed from the called number or a post-dial string. This approach does not require the gateway to have any prior knowledge of the number in order to route the call. 10. Security Considerations This document suggests using the Domain Name Service to resolve telephone numbers, and is therefore subject to the same security issues as DNS. 11. Acknowledgements The author would like to thank the following for their discussion or other contribution to this documents: Robert Sparks Steve Donovan Orit Levin William Marshall Jonathan Rosenburg Dean Willis References [1] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. Campbell Expires May 14, 2002 [Page 6] Internet-Draft SIP e.164 Resolution November 2001 [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. Author's Address Ben Cambpell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 email: bcampbell@dynamicsoft.com Campbell Expires May 14, 2002 [Page 7] Internet-Draft SIP e.164 Resolution November 2001 Full Copyright Statement Copyright (C) The Internet Society (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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Campbell Expires May 14, 2002 [Page 8]