[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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", <draft-ietf-enum-
   e164-dns-03.txt> 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", <draft-ietf-urn-naptr-rr-03.txt> (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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/