Internet DRAFT - draft-campbell-sip-e164
draft-campbell-sip-e164
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]
