Internet Engineering Task Force SIP WG Internet Draft Ben Campbell draft-campbell-sip-e164-00.txt dynamicsoft November 13, 2000 Expires: May 2001 E.164 Resolution in SIP 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. Abstract This document describes how SIP may use the DNS to resolve services associated with E.164 numbers, as specified in [1] Introduction There are several situations where a SIP User Agent [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 presumably knows what to do with it. [1] describes a method of using DNS NAPTR[3] 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. Terminology The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" Campbell [Page 1] draft-campbell-enumsipE-.01064 Number Resolution in SIP 21 September 2000 in this document are to be interpreted as described in RFC2119. Scope of Document This document describes when a SIP user agent should use the method described in [1] to resolve E.164 telephone numbers. It does not describe the actual details of telephone number resolution, since they are well defined in [1]. Neither does it describe the provisioning of the telephone numbers in DNS in the first place. 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 Both examples describe a globally-scoped telephone number (i.e. E.164 number). An important aspect of an E.164 number is that it is globally addressable. [1] specifies the use of the DNS domain of "e164.arpa" for globally addressable numbers. A user agent 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. [1] states that a prefix of "+" before the digit string designates the number as globally addressable. User Agent Client A UAC may need to send a request to a resource associated with a telephone number. It may need to start a new call to the resource, or it may have received the number as a contact in an existing call leg. When a UAC needs to send a request to a resource associated with an E.164 number, it SHOULD make a DNS query to resolve the number if it was presented in the form of a tel URL. It SHOULD NOT use a DNS query to resolve a number that was presented as part of a SIP URL. A UAC that is configured to use a local outbound proxy SHOULD not use enum. It should instead delegate that responsibility to the proxy. 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 Campbell [Page 2] draft-campbell-enumsipE-.01064 Number Resolution in SIP 21 September 2000 case, the request destination should be the host pointed to by the host part of the URI. The decision of how to handle the telephone number should be delegated to the destination device. Proxy When a proxy receives a request with an E.164 number in the requestURI, it MAY use DNS to resolve the number, depending on local policy. In this case, a proxy MAY use DNS to resolve an E.164 number contained in a SIP URL, if the domain part of the URL is owned by the proxy. 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 location services first, and use DNS only when the location service had no contacts associated with the requestURI. PSTN Gateway A PSTN to SIP gateway MAY use DNS to find resources associated 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. A gateway MUST NOT use the "e164.arpa" domain to resolve a non e.164 number. It MAY use other domains to resolve non-e.164 numbers. 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. DNS Query results [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 SHOULD be resolved according to the normal SIP address resolution rules. A SIP application SHOULD 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", only URIs with service fields of "sip+E2U" and "tel+E2U" should be present in DNS for the purpose of being used by a SIP UA. Campbell [Page 3] draft-campbell-enumsipE-.01064 Number Resolution in SIP 21 September 2000 The application SHOULD handle the NAPTR order and preference fields as specified in [1]. The final result of the ENUM resolution SHOULD 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 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. Application Examples The following are some examples of applications that could be facilitated using DNS resolution of resources associated with e.164 telephone numbers. E.164 Number as a Universal Identifier Using DNS to resolve resources associated with telephone numbers would allow the same number to be used whether reaching a user via the PSTN or over the Internet. For example, a users telephone number could be used as a key to determine a SIP URL, Mailto URL, or other identifiers. The user's business card would only need the one number instead of the common series of URLs and addresses common today. The author does not propose that a telephone number is a good choice for a universal identifier. In fact, a number is fairly non-mnemonic as identifiers go. This example is intended as an example only, and is in no way prescriptive. 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. 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. Open Issues Campbell [Page 4] draft-campbell-enumsipE-.01064 Number Resolution in SIP 21 September 2000 Should this draft go into more detail on how an application should interpret the resulting NAPTR RRs, specifically concerning the order and preference fields? This is specified in [1], but it might improve clarity to restate it here. 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. Acknowledgements The author would like to thank the following for their discussion or other contribution to this draft: Robert Sparks Steve Donovan Jonathan Rosenburg Dean Willis References [1] P. Faltstrom, "E.164 number and DNS", Internet Draft, Internet Engineering Task Force, August 2, 2000. Work in progress. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Session Initiation Protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [3] Mealling, M and R Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", (work in progress), June 1998. [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. Author's Address Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA email: bcampbell@dynamicsoft.com Campbell [Page 5] draft-campbell-enumsipE-.01064 Number Resolution in SIP 21 September 2000 Campbell [Page 6]