2.6.17 Telephone Number Mapping (enum)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Scott Petrack <scott.petrack@metatel.com>
Richard Shockey <rshockey@ix.netcom.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:enum@ietf.org
To Subscribe: enum-request@ietf.org
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/

Description of Working Group:

This working group will define a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g. URLs) which can be used to contact a resource associated with that number.


Telephone numbers now identify many different types of end terminals, supporting many different services and protocols. Telephone numbers are used to identify ordinary phones, fax machines, pagers, data modems, email clients, text terminals for the hearing impaired, etc.

A prospective caller may wish to discover which services and protocols are supported by the terminal named by a given telephone number. The caller may also require more information than just the telephone number to communicate with the terminal.

As an example, certain telephones can receive short email messages. The telephone number is not enough information to be able to send email; the sender must have more information (equivalent to the information in a mailto: URL).

From the callee's perspective, the owner of the telephone number or device may wish to control the information which prospective callers may receive.

The architecture must allow for different service providers competing openly to furnish the directory information required by clients to reach the desired telephone numbers.

Working Group Goals and Scope:

The working group will specify a DNS-based architecture and protocols which fulfill at least the following requirements:

1. The system must enable resolving input telephone numbers into a set of URLs which represent different ways to start communication with a device associated to the input phone number.

2. The system must scale to handle quantities of telephone numbers and queries comparable to current PSTN usage. It is highly desireable that the system respond to queries with speed comparable to current PSTN queries, including in the case of a query failure.

3. The system must have some means to insert the information needed to answer queries into the servers via the Internet. The source of this information may be individual owners of telephone numbers (or the devices associated to the number), or it may be service providers which own servers that can answer service-specific queries. The system shall not preclude the insertion of information by competing service providers (in such a way which allows for the source of the information to be authenticated).

4. The system shall enable the authorization of requests and of updates.

5. The Working Group will carefully consider and document the security and performance requirements for the proposed system and its use.

6. The Working Group will understand the impact of developments in the area of local number portability on the proposed system.

The Working Group will take into consideration how number resolution using the ENUM system is affected by the PSTN infrastructure for telephone numbering plans, such as the ITU-T E.164 standard.

The area directors will consider chartering an additional working group to pursue a non-DNS-based approach, if there's a constituency for the approach and a viable charter.


1. ENUM shall not develop any protocols or system for routing calls of a specific service or for locating gateways to a specific service. One example of such a service is mobile telephony, and one example of such gateways is IP telephony gateways.

2. ENUM shall not develop protocols for the "intelligent" resolution of these queries. That is, the updates to the ENUM data are limited to the insertion, update, and removal of URL information, and will not include inserting "logic" into the servers (to be used to respond to queries in an "intelligent" manner). (Of course, servers are free to support such intelligent services, but the insertion of such logic is not the object of ENUM standardization).

Document deliverables:

1. Telephone Number to IP Mapping Service Requirements (Informational)

2. Telephone Number to IP Mapping Service Architecture and Protocols (Standards Track)

These documents will specify the architecture and protocols (query, update) of the ENUM system.

3. A MIB for managing the service

4. The Working Group may decide to deliver a document which describes the relation between ENUM and E.164 or other PSTN telephone number infrastructure.

Goals and Milestones:

Nov 99


Initial draft of Service ENUM Requirements

Jan 00


Initial draft of ENUM Protocol

Mar 00


Revised draft of ENUM Service Requirements

Mar 00


Revised draft of ENUM Protocol

Mar 00


Possible draft on relation between ENUM and E.164 or other PSTN infrastructure

May 00


Initial draft of ENUM protocol MIB.

Jul 00


Submit ENUM Requirements document to IESG for publication as Informational

Jul 00


Submit ENUM Protocol document to IESG for publication as Proposed

Jul 00


Possibly submit ENUM relation with E.164 / other PSTN document

Sep 00


Submit MIB document to IESG for publication as Proposed


No Request For Comments

Current Meeting Report

Richard Shockey (rshockey@ix.netcom.com)
Scott Petrak (scott.petrack@metatel.com)

Jay Hilton (jhilton@telcordia.com)

Meeting Agenda
1 Agenda Bashing - 5 min
2 Document Status: Chair 2 min

3 ENUM Open Requirements issues ­ Greg Vaudreuil x min
3a. ENUM Operations issues... Greg Vaudreuil 20 min

4 ITU e164 workplan Andy Galant 10min

5 Service Principles when Public Circuit Switched International Telecommunication Networks Interworking with IP-based Networks - Steve Lind 15 min

6 ENUM Call Flows for VoIP Interworking . Steve Lind 15 min

7 ENUM in Signaling Transport: 20 min John Loughney

8 ENUM Usage in Cellular Roaming John Loughney 10 min

Future Directions and revised milestones 10m

DELETE: FAQ ­ Operations vs Out of Scope issues


Related Documents:

ITU Number Portability

Number Portability in the GSTN: An Overview

Dynamic Delegation Discovery System (DDDS)

URI Resolution using the Dynamic Delegation Discovery System


1. Agenda Bashing
Richard Shockey opened meeting with request for comments for additions or deletions from the agenda. The agenda was approved.

General Opening Comments:
(1.) Richard Shockey noted there were two number portability ID for discussion and possible review however these were not part of the agenda: ITU Number portability draft from ITU-T Study Group 2 and number portability in the Global Switched Telephone Network (GSTN) explaining applications in use in North America. These may be proposed as Informational RFCs at some time in the near future.

(2.) Scott Bradner noted that he had received some flack regarding the specification of a particular vendors application in a document. When identifying existing applications/implementations in draft documents we need to identify all or no vendors in the document.

(3) Richard Shockey noted that there are several other drafts that impact on ENUM work, in particular the new Dynamic Delegation Discovery System documents, draft-ietf-urn-dns-ddds-database-00.txt and draft-ietf-urn-uri-res-ddds-00.txt. Principals included within are a core part of NAPTR RR itself. It was noted in the Application Area General Session that these documents are fundamental to ongoing work in solving the problems of Service Resolution and eventually Capabilities Resolution RESCAP. Greg Vaudreuil asked about the limitation of only using NAPTR for ENUM. Scott Petrack noted that we will also use CNAME and DNAME for delegation purposes etc. The charter identifies that ENUM will provide a resource in the Internet, e.g., a URL. Therefore, the result of an ENUM query is a URL. Christian Huitema noted that ENUM results in two queries, one to find the URL, the second is to resolve the URL. Add note was agreed from the ENUM Charter, as quoted from Scott. "The system must enable resolving input telephone numbers into a set of URLs which represent different ways to start communication with a device associated to the input phone number." Scott noted simply "Telephone Number IN ..URL OUT". The chair requested that discussion of the limitation on use of the NAPTR record only be deferred until the General Discussion since it had been clear from the discussion on the list that this was the most contentious issue in the Falstrom e164-dns-01 drafts.

2. Document Status: Chair began a discussion of current Document Status.

2.1 Core ENUM Protocol Document - e164-DNS submitted to IESG Last Call

A URL for this Internet-Draft is:

This is the ENUM protocol document. It has been submitted for IESG LAST CALL. Some minor comments received (editorial and suggestions for adding another example which clarify differences between delegation of name servers in DNS and then further explanations of telephony applications). These will be incorporated in the document.

2.2 Requirements submitted to IESG Last Call

A URL for this Internet-Draft is:

Richard did not submit the document for last call due to the number of comments received over the email list. The plan is to resolve the outstanding issues in the very near future and then go to last call. The meeting discussed several open issues with the document. Greg Vaudreuil presented these issues for the author, Anne Brown, since she was not able to attend this meeting:
Issues with the Requirements Document Resolved at the meeting:
As part of the discussion of Requirements issues Greg Vaudreuil presented a series of slides.

Response Timeout: Draft indicated there must be a mechanism. Need more detail as to what should be provided, how long should a client wait before timeout? Is it a requirement? Christian Huitema proposed that no value be provided, therefore the application can set its own value.
CONCLUSION: It was agreed by the meeting that Response Timeout is NOT a requirement for ENUM.

DNS Security: Should authorization be a part of ENUM? Integrity? Privacy?
CONCLUSION: This was agreed to be dropped as a requirement for ENUM.

Availability and reliability: GSTN Reliability is desired.
CONCLUSION: This is an operational requirement, not a protocol requirement and therefore the meeting agreed that this is NOT an ENUM requirement.

Response Time: 95% within 2 secs. Is that achievable? Question regarding what is the DNS packet loss and will this work with the proposal? There is a 20% or greater chance of exceeding this requirement. Christian noting that we would exceed this requirement very often. Should this be an operations requirement? Scott Bradner suggesting that we include the PSTN requirement as a piece of information. Much of that information is contained in a variety of SIGTRAN documents. No specific ID were mentioned. Proposal to add notes regarding what the PSTN requirements are for both reliability and response time.
CONCLUSION: It was agreed that this is NOT a hard and fast ENUM requirement.

Corporate Dialing Plans: Use of ENUM for private dialing plans may be outside of the scope of this work. These are not e.164 numbers, which is the scope of ENUM.
CONCLUSION: It was agreed that this is NOT an ENUM requirement. However Richard Shockey noted that there was nothing precluding the use ENUM by private dialing plans.

Capabilities Discovery: ENUM identifies services and a service is something that can be identified by a URL. ENUM will not negotiate services. RESCAP will identify the capability.
CONCLUSION: The meeting agreed that this is NOT an ENUM requirement. More discussion in the general discussions below.

3. ENUM Operations issues... Greg Vaudreuil
A URL for this Internet-Draft is:

Recommended TTL: Need clarification between services needing slow updates (15 minutes) and those needing fast updates (out of scope for ENUM)
CONCLUSION: Do NOT add text on how to change TTLs.

Number portability: How repointed DNAME, CNAME, etc, or changing the provider of a particular service via NAPTR, should be reflected. Proposal to identify in some internationally generic manner. Need to continue this discussion on the mailing list. Good idea to distinguish these 2 cases in the document. There is an issue of control as well as portability in this discussion.
Change Propagation Rate: Is 15 minutes a worldwide time frame? No complaints.
CONCLUSION: Leave as is.

4. Service Principles when Public Circuit Switched International
Telecommunication Networks Interwork with IP-based Networks.
A URL for this Internet-Draft is:

Steve Lind is the rapporteur for Question 10 in ITU-T Study Group2. This was developed by Q10/2 and is planned for approval at the January 2001 meeting of SG2. Proposal is to further the collaborative effort between SG2 and IETF.
From the draft document: This document describes the current thinking of the collaborators of ITU-T Question 10/2, "Management and development of PSTN-based telecommunication services," about service principles when public circuit switched international telecommunication networks interwork with IP-based networks. This document contains most of the text (there has been some rearrangement of the text) from draft new Recommendation E.370 [1], starting from section 3 of this Internet Draft, which was determined to be stable at the March 2000 meeting of Study Group 2. It may be approved by the members of the ITU, subject to written comments received from those members, at a meeting of the Study Group (or its successor) in early 2001 (provisionally 23-26 January 2001). It is hoped that this document will further the collaborative efforts between Study Group 2 and the various working groups of the IETF. Discussed possible service scenarios that utilize IP networks. Looking for input from IETF WGs. Post comments to the itu+ietf@ietf.org mailing list.

5. ENUM Call Flows for VoIP Interworking . Steve Lind

Genesis of this document was the IP Telecoms workshop held in January 2000, in Geneva, Switzerland.
The issues identified within this document include:

The document proposed that while some of these issues may be outside the scope of ENUM, they nevertheless have to be addressed if IP-based communication will be viable. Between the IETF and the ITU, core competencies exist to address these issues; continued cooperation will be beneficial. It has been proposed to submit the results of the collaborative effort as an ENUM WG RFC.

6. ENUM in Signaling Transport: John Loughney

A URL for this Internet-Draft is:
This document describes the use of ENUM Services by SIGTRAN Protocols. A question was raised regarding how do we handle address resolution issues?

Christian Huitema arguing against the proposal in the document. Suggesting that Gateway discovery protocol developed by IPTel would be more appropriate than the ENUM proposal.

7. ENUM Usage in Cellular Roaming John Loughney
A URL for this Internet-Draft is:
This document is a first draft that proposes a new service, called 'roam' to enable roaming in cellular systems (2G, 3G), supported by using the ENUM solution for DNS resolution of E.164 numbers. By querying DNS for the roaming service entity for the particular E.164 number, DNS can return the location of the network element that supports the cellular roaming services (i.e. - HLR, VLR, AAA server).

Scott Petrack noted that the application of ENUM as a solution should result in a URL. No decision by the group.

8. ITU Number Portability Andy Gallant
A URL for this Internet-Draft is:
This document contains a text version of the Number Portability Supplement (11/98) to ITU-T Recommendation E.164 (The international public telecommunication numbering plan, 05/97) [2]. That Supplement [3] defined terminology for number portability within an E.164 numbering scheme; identified formats, call flows, architectures, and routing approaches for some methods; and gave examples of some processes needed to implement number portability.

This document was presented for information to the ENUM WG.

9. ITU e164 work plan Andy Gallant
A URL for this Internet-Draft is:
The presentation of this material was made by Andy Gallant. This is an unofficial snapshot of some of the E.164 work. It includes some information on E.164-series ITU-T Recommendations, "country code" assignments, and future pending decisions, meetings, and work. There was a question regarding the use of subaddressing numbers in ISDN numbering that may come into play with VoiceMail services. The answer was not clear and interested parties need to follow-up on this question after the meeting. The presentation provided a valuable insight into the definition and operation of the Numbering work within the ITU-T. Andy also provided an identification of the ITU documents of interest to the ENUM group. Scott Bradner noted that the ITU and the Internet Society are members of each other's organization and can send reps to each other's meetings.

Question from the floor: Is there a relationship between the hierarchical nature of E.164 and DNS? Yes, at the highest level they are administered by a central body with the lower level being administered locally.

10. Future Directions and revised milestones

Also, a need was expressed for some type of transition scheme from Non ENUM to ENUM usage.

11. Richard Shockey noted that he had posted a ENUM FAQ - At the request of the AD's this document will eventually be segmented into Protocol questions ..which could move forward to Informational RRC as a WG product vs Operations and Administrative issues which would be a personal ID.

12. General discussion...
Chairs reopen the question of NAPTR use.

Are we making a requirement that ENUM use NAPTR record types only? The chairs state categorically that ...Yes, that is what is in the e.164 dns draft that is in IESG last call status. There are other ways to use different schemes than NAPTR and they could be identified in an Informational RFC but ENUM is about the use of NAPTR records.

Question ..does NAPTR Queries return all records?

Answer : Yes there is no selective query. Discussion follows that it MAY require the opening of a TCP connection if there are too many RR's. It is noted that NAPTR is new and untested but offers considerable power.

Greg Vaudreuil notes that there is still objection to this requirement.

Chairs call for a show of hands... Question... Shall ENUM use NAPTR record types only?


Meeting Concluded.


None received.