Telephony’s Next Act



There are about 1 billion fixed telephone lines and 2 billion cellphones in the world. Most calls still travel across traditional systems based on proprietary software and hardware. Soon, though, they will move to networks based on open protocols—known as voice over Internet Protocol (VoIP).

The same thing is happening all around the world—in some cases very quickly. Last winter, the chief technology officer at BT Group PLC, in London, said that during the next three to five years, BT would like to “turn off the public switched telephone network.”




The traditional telephone networks and the Internet handle signaling very differently. Voice customers use traditional phone numbers, while the Internet is based on domain names, such as my company’s “,” and numerical Internet addresses, such as “” Voice callers will want to keep their phone numbers, even as the calls move to the Internet. At the same time, Internet users will want to place calls by clicking a browser link or perhaps by selecting a menu item on a PlayStation or other game machine. They’ll also want to start phonelike conversations and Internet chat sessions, and to use videoconferencing software on their laptops and PDAs. So VoIP will have to support e-mail and Web addresses as well.

In many ways, the problem of merging these two different leviathans comes down to merging their respective databases, which is to say their searchable collections of data records. A few years ago, Internet standards bodies approved a new type of data record—called ENUM, for electronic number—that could accommodate the legacy information of both telephony and the Internet. ENUM will be the bridge between the two global communications networks. Among other things, it provides a simple way to turn a phone number into an Internet address.

As we will see, ENUM offers an opportunity to revisit in a fundamental way the Internet’s design, creating an open standards based approach to the way we identify network devices and the people who use them. Openness is key if we are to ensure that tomorrow’s VoIP world is as open and interoperable as the Internet itself has been. There’s a danger that regions will instead be cordoned off by some private VoIP providers, such as Luxembourg-based Skype, that encourage their customers to use names specific to their systems.




One of the basic concepts is a fully qualified telephone number, such as +1 650 381 6115 or +41 22 730 5111. This is defined by an International Telecommunication Union standard known as E.164. All ITU-T E.164 numbers are 15 digits or fewer and start with a country code (+1 for countries on the North American numbering plan, +41 for Switzerland, and so on), suballocated by the corresponding national bodies under nation-specific policies. The “+” denotes a complete phone number. Don’t, however, be confused by the common U.S. phrase, “call 1-800 [number]”; services such as the toll-free numbers, 911, and directory assistance are processed in a country-, carrier-, and region-specific way and routed to their final destinations.

The Internet, on the other hand, employs several kinds of identifiers. Perhaps the most basic is the domain name, supported by a highly distributed network called the DNS, for Domain Name System. If, for instance, you point your browser at the domain name, your computer will query your local DNS server for all the IP address records—numerical codes signifying physical machines in the Yahoo network—that are associated with that domain name. And if you write me at, your mail server will ask for the corresponding codes (called MX, or mail exchange records) that are associated with mail for the domain name “”

Let’s look at the latter case in some detail. If your query is a very common one, then perhaps the local network server in your company will have cached the answers to it, obviating the need to relay it beyond the building’s walls. If, on the other hand, the answer to the query isn’t cached, your server will relay the query through the Internet to Nominum’s name server, prompting the server to send you a response. That response, represented in text, would read as follows: 3600 IN MX 500 3600 IN MX 5 3600 IN MX 10

These three records identify three different mail servers; Nominum maintains two to provide redundancy against the possibility of the main mail server’s failure. Each MX record contains the name of the mail server and a preference value that tells the order in which the servers should be used, beginning with the lowest value (“5,” in this case).

How did your name server find Nominum’s? Internet names are interpreted from right to left, beginning with the domain name’s suffix—.com, .org, .arpa, .uk, .de, .aero, and so on. A local server looking for information about, and starting with no cached information, would go to one of the 13 root servers spread out across the globe and find the identity and address for name servers having information about .com addresses. The server would then redirect the query to a DNS server, which would send back the correct numerical address for






ENUM is an international phenomenon. Here’s an example for the U.K. phone number +44 1632960083, with data from domain name

NAPTR 10 101 “u” “E2U+email:mailto” “!^.*$!!” .

NAPTR 10 102 “u” “E2U+sms:tel” “!^.*$!tel:+441632960083!” .

NAPTR 10 100 “u” “E2U+sip” “!^.*$!!” .

The key variable here lies in the space occupied by “mailto,” “tel,” and “sip.” These elements refer, respectively, to an e-mail application, POTS, and the SIP, the Internet Engineering Task Force’s signaling protocol. (Among other things, SIP is what allows an instant-messaging buddy list to say which of your friends is online the same time you are.) So these database statements tell any inquiring network that the customer in question can be reached via SIP, via e-mail to, or via conventional telephony. The numbers specify that the caller (or a calling software program) is asked to use SIP first, and if that doesn’t work to try mail or telephony.





So, WILL the Internet handle the load? The answer is yes, with a large caveat. First of all, the “pipes” themselves—that is, the fiber-optic cables in the Internet backbone—are fat enough, and new technology is always coming along to make them effectively fatter.

But the other part of the system, the DNS, is not quite so robust as many like to think. First, a merged world will require vastly more storage than today’s DNS system. NAPTR records will be larger, typically dozens of bytes, compared with today’s 4 bytes for IP addresses. In addition, there will be hundreds of millions of names to track in some servers, versus today’s entries, which generally run in the thousands. Even the .com database—by far the biggest—now has only 40 million names.

Second, it takes time to answer a DNS query, and such latency, as it is called, has so far been overlooked because it doesn’t matter for e-mail and is generally tolerated in Web page displays. Latencies in the tens of seconds are not unusual. Telephone callers, however, expect latencies of less than half a second.

Particularly in public ENUM, subscribers will want to view and change their own contact information and will expect changes to take place immediately. Often these changes will be automated or implicit as a phone comes within range of a Wi-Fi access point, for example. Many of today’s DNS servers have complex and lengthy update requirements; they will simply not meet these needs. Further, DNS servers will need to continue answering queries while they are being updated. Indeed, configuration and provisioning often require Internet service providers to take DNS servers off-line, at least briefly. People won't stand for such outages in telephone service. In short, today’s DNS servers cannot handle the challenges that ENUM will pose.

To measure the effects of ENUM, my company has studied the DNS server implementations that telephone companies commonly use: BIND Version 9.3.0 from the Internet Systems Consortium Inc., Daniel J. Bernstein’s DJBDNS, PowerDNS’s PowerDNS, and Nominum’s ANS, or Authoritative Name Server.



Moving to computers with 64-bit processors—which allows for much larger memory spaces—helped, but it wasn’t a panacea. In tests on a 64-bit Opteron processor, with test data of 10 million names, organized into groups of 10 000, BIND delivered 3805 queries per second and ANS 57 000 queries per second. Interestingly enough, BIND performance degraded by a factor of 50 when ENUM data were organized into separate groups as they might be for public ENUM.


If these issues aren’t faced, Internet users are likely to face higher costs and decreased quality of service, delayed call connections, and dropped calls. Alternatively, the provider could opt for a scalable solution, such as Nominum’s. (Of course, we believe that our solution is preferable.) This isn’t merely a service provider’s problem—it’s everyone’s problem. We all would like to be able to dial a phone number without worrying about what kind of service the recipient has. The Domain Name System needs to be upgraded with software tested against the high-volume, constantly changing loads of ENUM. Only by strengthening these DNS capabilities will we be ready for the demands of ENUM and other new network technologies. As the demands we face are new, so must our approach be new.

About the Author


To Probe Further

A useful primer on ENUM is at

An article in the March 2005 IEEE Spectrum, “Seven Myths About Voice Over IP,” offers some additional background information about the protocol.

Readers seeking more information about DNS can start with an article published by the Internet Society, “DNS Root Name Servers Explained for Non-Experts,” at and follow its links.