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]
