Many communications networks are constructed for a single form of communication, and are ill suited to being used for any other form. Although the Internet is also a specialized network in terms of supporting digital communications, its relatively unique flexibility lies in its ability to digitally encode a very diverse set of communications formats, and then support their interaction over the Internet. In this way many communications networks can be mapped into an Internet application and in so doing become just another distributed application overlayed on the Internet. From this admittedly Internet-centric perspective, voice is just another Internet application. And for the growing population of Voice over IP (VoIP) users, this is indeed the case. Being able to transmit voice over the Internet is not enough. Allowing one Internet handset to connect to any other Internet handset is still not enough. In the same way that walkie-talkies became ubiquitous mobile phones only when there was a seamless integration with the telephone network, a truly useful VoIP approach will be one that supports seamless integration with the telephone network.

The basics of the telephony world are very simple indeed. Telephone handsets are little more than a speaker and a microphone. When a call is made, the network connects the microphone of one party to the speaker of the other, and vice versa. Of course you don’t need a specialized telephone network to support the carriage of voice. As any user of a desktop computer would confirm, there are now a plethora of applications that can deliver a voice signal across the network. For an application to support a voice conversation, a conventional approach is to use a network base of the User Datagram Protocol (UDP) transport protocol, with a Real-Time Protocol (RTP) overlay, and the RTP payload is an encoded version of the original analogue voice signal. Carrying voice signals in real time across an Internet is a well-understood network service, with an accompanying set of existing protocols and associated applications.

E.164 Addresses and IP Services

However, being able to transmit voice signals across a network is not enough. It was Strowger’s step-by-step switching system of the late 19th century that transformed the telephone into a truly useful communications network, allowing any telephone subscriber to initiate a conversation with any other subscriber. This has evolved today into a global numbering plan where every device connected to the telephone network is assigned a unique numerical address. This numbering plan is administered by the International Telecommunication Union (ITU), and the plan, Recommendation E.164, involves the assignment of number prefixes to each country code administrator [1].

If the Internet voice domain interoperates seamlessly with the telephone network, supporting this E.164 numbering plain into the realm of the Internet is a critical step. To make Internet telephony truly useful, the Internet telephony world has to be able to interface to the telephone network by allowing Internet-connected telephone devices to make and receive calls to any other telephone device, whether the other device is connected to the Internet, connected to the telephone network, or connected to any other network that seamlessly interoperates with the telephone network. For this to work, one of the preconditions is that every Internet device that supports telephone operation needs to also have an alias in the form of a unique telephone address. But there’s a bit more to it than simple numbering.

Each Internet telephone is also an IP device, and, for the Internet component of the end-to-end path, the voice traffic will be carried by IP packets. These packets obviously require the IP address of the Internet telephone device. So each Internet telephone requires both an Internet address and a telephone address. It is the mapping from a telephone number to an IP address that is the crucial part of this function.

Consider an example. When Alice, on a normal telephone, wants to call Bob, on an Internet phone, all Alice needs to do is simply dial Bob’s telephone number, or his E.164 address (Figure 1). Of course, because Bob’s phone is connected to the Internet and can’t directly receive Alice’s call request, a gateway is necessary. The telephone system should be able to map Alice’s call request to the Internet telephony gateway that is configured to act as Bob’s gateway agent. The gateway then needs to translate Bob’s E.164 phone number into an IP address. Then the gateway has to map the telephone network signals associated with Alice’s call request to corresponding signals within an Internet session initiation protocol, and then send these IP packets to Bob’s Internet phone. If Bob answers the call, the phone uses the same protocol to inform the gateway, which then sends a corresponding telephone call code across the telephone network to Alice.

When Bob accepts the call, the gateway can then pass all data originating from Alice to Bob’s IP address, and all data received from Bob’s IP address across to the telephone connection to Alice for the duration of the call. Alice never needs to know that Bob is using an Internet device. Alice dialed a phone number, heard it ring, and then heard Bob answer the call. For Alice, nothing has changed. Bob heard the phone ring, picked it up, and talked to Alice. For Bob, nothing has changed.

The simplest way to configure each gateway is to load each gateway with a configured list of E.164 phone numbers and corresponding IP addresses. This approach is currently very common, but, like all statically configured approaches, has its weaknesses. But what happens when the IP device is numbered dynamically using the Dynamic Host Configuration Protocol (DHCP), or if it’s mobile, and moves from one service provider’s IP network to another, or when the end subscriber changes providers and that subscriber’s network is renumbered, or when the primary gateway fails and the providers want to switch to a secondary device? In other words, how can this mapping be dynamic rather than static?

The way a dynamic domain name-to-IP address mapping can be maintained on the Internet is through the Internet Domain Name System (DNS). The telephony gateway can use the the E.164 address as the DNS query, and request the DNS to return the corresponding IP address. In our example, when Alice rings Bob, the gateway can use the DNS to obtain Bob’s current IP address. The gateway can then use the Session Initiation Protocol (SIP) to send to Bob’s Internet phone a call request, which then starts Bob’s phone ringing. If Bob changes IP address, then the corresponding change is a change in the DNS, not in the gateway itself. If the primary gateway fails and a secondary gateway is used, the secondary system can already access all necessary mappings through the DNS.

So the general approach of using the DNS to contain this mapping is one with some merit, but, as always, the devil is in the details. There are two parts to mapping a E.164 number into the DNS. The first is the nature of the transforms to be applied to the E.164 address to obtain a DNS query string, and the second is the form of the DNS response to this query.

Mapping E.164 Addresses into DNS Query Strings

One possible approach to mapping an E.164 number into the DNS is to simply place numbers as text blocks into the DNS. In this way, the number +61-0-12345678 could be mapped to the DNS string 61012345678.example.com. If this method were to be used for a sizable number of E.164 numbers, there are obvious DNS performance implications associated with the size of this DNS zone file, together with the issue of frequency of update of the zone and its cache characteristics.

There are also a large number of E.164 country code delegated authorities and, consequently, a large number of entities who would like to be the authority for parts of such a monolithic unstructured DNS zone file.

In order to avoid these issues, some structure in the E.164 address space has to be used to map into the hierarchical name structure used in the DNS. One helpful observation is that E.164 numbers and Internet domain names use opposite ordering. Whereas a fully qualified domain name, such as test.example.com, has the more specific parts to the left and the most general part, the root, on the right of the name, a telephone number code has the most general part, the reference to the country code prefix “+ ” to the left and the more specific parts to the right. If one were to reverse the order of E.164 symbols, then the two address domains would have a similar structure.

One of the first efforts to provide a mapping between E.164 number and the DNS was part of the TPC fax gateway service, started in 1993 [2]. This approach uses a reversed E.164 number, and treats every digit as a node on the DNS name hierarchy. In our example, the E.164 address +61 0 12345678 would map to the DNS query string 8.7.6.5.4.3.2.1.0.1.6.tpc.int. (in the TPC service, the parent DNS zone of this mapping is tpc.int.)

This mapping has some very convenient properties. Each country code corresponds to a delegatable DNS domain, so that the international country code for Australia, +61, can have a corresponding DNS delegation for the zone 1.6.tpc.int. Within the country code the DNS can be further delegated to operators in a manner that parallels the further delegation of E.164 common prefix number blocks.

This same mapping is used by ENUM, using a DNS name parent of e164.arpa . The mapping entails taking a complete E.164 address (including the country code), and then removing all nondigit symbols from the address. The digit string is reversed and a “.” is placed between each pair of digits. The string .e164.arpa. is then appended to make a complete DNS query string. Using this process, our example number +61-0-12345678 is transformed into the DNS query: 8.7.6.5.4.3.2.1.0.1.6.e164.arpa.

Although this form of mapping is technically well suited to the DNS, it does mean that the DNS equivalent of the E.164 address is not very easily adapted to our conventional use of telephone numbers. The implication is that it is likely that Internet-based telephony applications will continue to present E.164 numbers in their user interfaces as conventional telephone numbers, and manipulate the DNS equivalent strings as internal objects.

The DNS Response

The telephone network supports more than simple voice conversations, and any serious attempt to bridge the telephone network and the Internet also should be able to also handle various forms of text messaging and paging services as well as document transmission undertaken as faxes. The desired outcome is that the interface between the telephone network and the Internet should be able to seamlessly redirect the telephone service to the appropriate Internet service. In other words, we are seeing a requirement that a set of services associated with the same E.164 address should be able to be mapped to a set of IP servers, rather than a single server with a single IP address.

The implication is that the DNS response to an ENUM query should have a richer functionality than simply returning a single IP address. In DNS terms, associating a conventional “A” DNS resource record with each ENUM domain name is not sufficiently flexible for our purposes.

The approach adopted by the TPC fax gateway service was to map a fax in the telephone environment to an e-mailed multimedia message in the Internet environment. To support this mapping, telephone numbers were mapped to DNS Mail Exchange (MX) resource records, and these records were mapped to a mail server’s IP address in a second DNS lookup.

ENUM attempts to solve a more general model of providing mappings for any relevant service. One possible approach is to use a collection of DNS name roots, one for each mappable service. Thus, for example, fax.e164.arpa. could hold mappings for the fax service, while voice.e164.arpa. could hold mappings for voice services, and so on. However, this approach is not consistent with the generic architecture of the DNS, and the distribution of service information has the potential to lead to synchronization errors. Usefully, the DNS allows a collection of resource records to be associated with a DNS name, and this set of records is returned as the answer to a query. It is then left to the application to determine which particular record to use, with perhaps some preference hints provided in the DNS response. The approach used by ENUM takes advantage of this DNS capability, and ENUM uses the DNS to map an e164.arpa number onto a collection of service-specific Uniform Resource Identifiers (URIs) [3].

A gateway that uses ENUM to query the DNS will receive the complete collection of service-specific URIs in response to a request to translate an E.164 address to a URI. Depending on the type of service being requested, the gateway can then select the most appropriate URI and use the DNS a second time to translate the domain name part of the URI to an IP address using the URI-specific DNS resource record as a query term. The gateway can then use the full URI specification to open an IP session with the selected service port and complete the service transaction.

The URI resource records used by ENUM are Naming Authority Pointers (NAPTR) records [4]. This form of use of the DNS allows for entries where the entry itself can be decomposed into further delegations, using name formats that use URI syntax [5].

NAPTR fields contain numerous components:

• An Order field to specify the order in which multiple NAPTR records must be processed
• A Preference field to determine the processing order when multiple NAPTR records have the same order value
• A Service field to specify the resolution protocol and service
• Flags to modify the actions of further DNS lookups
• A regular expression to allow the query client to rephrase the original request in a DNS format
• A Replacement field to define the next DNS query object

The intended operation of ENUM is to first take the E.164 number and convert it to a query in the e164.arpa domain. The resultant set of services is specified by the returned collection of NAPTR records. The agent selects a service that matches the service characteristics of the original request, and takes the corresponding URI for further resolution by the DNS. The elements of this URI are further decomposed as per any rewrite rules in the NAPTR record. DNS queries are generated as per the sequence of preferred NAPTR rewrite operations. The ultimate result of this sequence of DNS queries is the specification of a protocol, an associated port address, and the IP address for a preferred server for the service.

An Example of the Use of ENUM

Let’s say Bob’s Internet telephone services are mapped to the E.164 address +61-0-12345678. When Alice tries to call Bob, the telephone network routes the call request toward the Internet gateway that is the nominated service agent for this E.164 number. The Internet gateway takes the call setup request with Bob’s number and first reverses the digits, then inserts a “.” between each digit, and finally appends e164.arpa. The resultant DNS string is the fully qualified domain name 8.7.6.5.4.3.2.1.0.1.6.e164.arpa. This name is then passed as a query to the DNS, to retrieve all associated NAPTR DNS resource records.

Bob has specified that he prefers to receive calls using SIP addressed to user bob at the server telebob.au by placing the following in the DNS:

In this case the DNS entry uses an order value of 100 and a preference of 10. The “u” flag indicates that the rule is terminal and that the specified URI is to be used. The service field specifies that the SIP protocol is to be used, in conjunction with the E.164 to URI (E2U) resolution service [6]. The operation of the regular expression produces the URI of the form sip:[email protected].

For this call request, the gateway picks the sip+E2U service and performs the associated regular expression transform using the original E.164 number and the regular expression. This produces the sip: URI. The gateway then uses the DNS a second time to translate the domain part of the URI, sip.telebob.au, into an IP address using a DNS A record.

The gateway then opens up a session with UDP port 5060 on this SIP server to complete the call setup, requesting a voice session with the user Bob on this server. (Figure 2).

If, on the other hand, Alice is sending Bob a short text message, then Bob may want this to be delivered to him as mail. Bob would add the following entry into the DNS:

In this case the gateway would use this mailto: URI and use the domain part of the URI as a MX DNS query. The DNS responses are a list of mail server names and associated preferences. The gateway then selects this more preferred server and resolves this name to an IP address by a further query to the DNS for an A address record.

The gateway can complete the original text message delivery request by opening a TCP session on port 25 of the mail server and sending the message as mail addressed to user [email protected].

Services in ENUM

Other URIs can also be associated with an E.164 number, even services not normally associated with a mapping of a telephone function. These may include http: URIs, even other E.164 telephone numbers, specified by tel: URIs.

Let’s complete the example of Bob, who wants his SIP phone, mail address, Web page, and mobile telephone to be referenced from a single telephone number.

Alice can enter the phone number 61012345678 into her browser and retrieve Bob’s Web page in response. She can address e-mail to this number and thereby send mail to Bob. Or she can make a telephone call to Bob’s SIP phone, and if it does not answer she can try Bob on his mobile phone. And she can do all this from a single number.

Numerous interesting technical issues still need to be resolved, such as the necessity and level of cacheing within the global ENUM system and the creation of a standard registry scheme for ENUM service definition.

The Politics of ENUM

There is quite some depth in the capabilities of the regular expression rewrite rules in ENUM, but the basic functionality is one of mapping a telephone number to a collection of service points that are associated with the telephone customer who was assigned that telephone number.

Despite this apparent functional simplicity, ENUM appears to have a powerful set of attractors for regulatory and social controversy.

A key benefit of moving into ENUM and the associated realm of IP-based voice communications is that service creation becomes a function of the edge and not the network. What were seen as telephone network functions such as no answer and busy redirect, call forwarding, number translation, and conference calls can all be implemented as edge applications driven by user scripts, rather than what we now see in the telephone network as value-added network-based services. One way of viewing this ENUM approach is that the DNS is functionally capable of assuming the role of service control point for telephone services, taking over the role undertaken by Signaling System 7/Channel 7 (SS7/C7).

Service creation and signaling are slipping away from the hands of network operators into the hands of enterprises and eventually consumers, in much that same way that the Internet has redefined other services in terms of edge-based function instead of network mediation.

There is also the issue of ownership of these ENUM DNS zones, or to put it another way: who gets to populate the e164.arpa domain with all these URIs? It could be that this is a responsibility of existing telephone service providers, because after all these entities operate the E.164 address space in each country. It could also be that this is a responsibility of Internet Service Providers (ISPs), because the data in the resource records is describing Internet-based services. Or maybe the end subscribers get to populate the DNS with their own entries, based on a collection of services that may be sourced from a set of providers.

It is quite conceivable that we could see ISPs that have no direct role in carrying voice traffic wanting access to a country’s E.164 number plant in order to provide various forms of ENUM services. Given that each element of an ENUM service collection can use URIs that refer to different ISP services, it is possible that the one ENUM record can be populated by URIs referring to numerous different service providers. This model of multi-agent access to such infrastructure resource records is a novel concept to many regulatory and operating regimes, where a single operator manages the entire associated infrastructure elements that are needed to deliver a service.

Some of the discussion about ENUM has been on more subtle aspects of this mapping. There’s the choice of e164.arpa as the common DNS root for ENUM DNS entries. At an international level there’s a lingering perception that “arpa” is too American and that a name root of “int” appears to be more neutral.

But there’s something else lurking here, which has surfaced within the regulatory debate in the United States. North America has the .164 country code of “1,” implying that under ENUM there is a single DNS domain for ENUM, namely 1.e164.arpa. Single domains imply single operators, and single operators have an implication of a noncompetitive monopoly service regime. There has been a call for multiple E.164 DNS root locations for North America, allowing for two or more competing service operators using different DNS hierarchies to locate their ENUM services.

On the one side there is the view that such attempts to create multiple partially populated ENUM name hierarchies to support competitive service provision in ENUM-based services are no more than an incitement to address and service chaos. This chaos would, in turn, seriously hamper the uptake of ENUM services.

On the other hand, the competitive provision proponents of multiple DNS root domains argue that a regulatory-sanctioned monopoly is still a monopoly, and this monopoly situation will likely lead to high service prices for ENUM services. This escalated pricing structure would, in turn, seriously hamper the uptake of ENUM services.

As we have seen with the use of multiple services for an e164.arpa entry, the proponents of ENUM envisage a single telephone number as being an alias not only for your Internet phone service, but also for instant messaging, e-mail, your Web page, and any other service that is associated with you. One identifier is all that would be required to reach you, using a service protocol and service provider of your choice. The implication of such a use of a telephone number is, on a personal level, no more business cards cluttered with phone numbers, fax numbers, mobile numbers, e-mail addresses, Web addresses, and instant-messaging handles. Phone numbers are still the most widely used naming scheme in communications, and the use of these numbers as a universal locator has the advantage of being linguistically neutral as well as enjoying almost ubiquitous use. There are no international character set issues within this particular number space. All we need is just one ENUM address, or just one number, for all these services.

One number to rule them all, one number to find them, one number to bring them all and in the darkness bind them” is the ENUM version of Tolkien’s saga [7].

But one person’s ease of use is often another’s opportunity to exploit. To be Lord of the Numbers would indeed be a powerful role if such uses of ENUM were to become widespread. In addition to the commercial opportunity in operating ENUM registries, ENUM can be seen as yet another erosion of personal privacy on the Internet. It can be viewed as one more step toward the use of single individual digital identity that could be used to track individuals within the Internet. On a more immediate and mundane level of concern it opens up the opportunity for spammers to use a wealth of new ways to drive you to complete distraction.

It appears that the technical components of ENUM are generally the most straightforward part. The regulatory and social implications of ENUM are more of a concern, and it is here that with ENUM we are entering into “the Land of Mordor where the shadows lie.”

Further reading:
[1] List of ITU-T Recommendation E.164 Assigned Country Codes, available online at.
[2] Malamud, C., and Rose, M., “Principles of Operation for the TPC.INT Subdomain: Remote Printing—Technical Procedures,” RFC 1530, October 1993.
[3] Fälström, P., “E.164 Number and DNS,” RFC 2916, September 2000.
[4] Mealling, M., and Daniel, R., “The Naming Authority Pointer (NAPTR) DNS Resource Record,” RFC 2915, September 2000.
[5] Berners-Lee, T., Fielding, R., and Masinter, L., “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 2396, August 1998.
[6] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., “SIP: Session Initiation Protocol,” RFC 2543, March 1999.
[7] Tolkien, J. R. R., The Lord of the Rings, George Allen and Unwin, London 1955.
[8] This site has a good overview of ENUM and its potential application as well as references to further ENUM resources.
[9] “Interim Approval for ENUM Provisioning,” see the Fragments section in this issue of The Internet Protocol Journal, page 37.