I have seen some hype building up about ENUM (RFC 2916) recently, suggesting that ENUM will finally make Voice-over-IP (VoIP) leapfrog traditional telephony.

First of all, what is ENUM? It is simply a means for a VoIP program like Microsoft Windows Messenger or Apple’s iChat AV to find how to reach a correspondent from a phone number. First-generation VoIP programs required users to enter the IP address of their correspondent to call them, or to use non-standard or semi-standard directory services like Microsoft’s short-lived ILS. Since most people wouldn’t recognize an IP address if it bit them on the nose, this limited the market to geeks or incredibly determined penny-pinchers. With ENUM, if you know my phone number, say (415) 359-0918, or if you use the ITU-T E.164 international numbering standard, +1 415 359 0918, you would find the IP address of my VoIP phone/program by looking up 8.1.9.0.9.5.3.5.1.4.1.e164.arpa in the DNS. This is the reversed E.164 phone number, with e164.arpa tacked onto it, the way you can do reverse domain name lookup of the IP address 198.144.198.154 by looking up the PTR record corresponding to 154.198.144.198.in-addr.arpa. The .arpa is a legacy of the days when the Internet was bankrolled by the US ARPA, now the Defense Advanced Research Projects Agency (DARPA), and cause no little grumbling from people who would rather have a more “neutral” root e164.int.

This is a clever hack, allowing VoIP clients to leverage the DNS infrastructure, rather than building new protocols or even leveraging existing ones like LDAP. Every modern computer from Palm PDAs to Windows PCs to IBM mainframes have built-in DNS clients (although few support the ridiculously over-engineered new NAPTR resource record introduced for ENUM in RFC 2915). LDAP client libraries are nowhere near as widespread. Implementing ENUM is thus relatively easy, in the order of a few days of work at most, assuming the underlying name client software is not hardwired for IP address resolution only. In a similar way, a few years ago a group of young turks unsuccessfully proposed the ITU set aside an international country code for VoIP calls (the decimal IP address would be encoded as a 12 digit phone number). The old ITU proposal addressed the issue of getting conventional phones to reach an IP address, ENUM addresses how to reach a conventional phone number from an IP phone.

That said, while ENUM simplifies some of the logistical issues of managing a federated namespace or numbering plan, the bulk of the effort in transitioning to VoIP lies elsewhere:

  • Making IP phones as convenient as traditional phones (waiting 5 minutes for Windows to boot does not quite qualify).
  • Providing the same level of resiliency as the old network, for instance in case of power failure (when I was in Telecom school, one of our teachers always insisted on the fact when phones fail, people can die because emergency services are not dispatched any more).
  • Providing gateways between traditional telephony and IP telephony, and finding a sound business model to pay for it.
  • Figuring out how billing and compensation will be handled
  • Increasing competition by allowing direct calls when both users are VoIP capable, without having to know this explicitly beforehand.
  • Improving the ubiquity of IP connectivity, specially residential broadband and wireless.
  • Improving IP network quality of service, since Quality of Service approaches do not scale and end up being even more inefficient than the old network.

ENUM does not address the chicken-and-egg syndrome that is slowing VoIP adoption. A significant proportion of telephone calls is now carried over IP, for instance AT&T and MCI have both declared their intent to migrate over half their voice traffic to IP by 2005. But that is invisible to end-users, and not accessible – you won’t be able to dial an AT&T user by the IP address AT&T uses internally for them. AT&T will not give it to you because then they would not be able to bill you for it the way they can bill other telcos with interconnect agreements.

As the global E.164 numbering plan is controlled by the ITU and delegated to Telcos, ENUM will not by itself make it possible to create new phone numbers that are not controlled by Telcos. A competitive service provider could petition to obtain a number range, the way Vonage obtained US phone numbers for its VoIP service, but telephone billing has assumptions on the structure of phone numbers deeply embedded within it, probably inextricably. After all, it has taken carriers over ten years to learn to bill calls towards mobile phones in Europe differently by detecting they have a leading 6 digit.

Conceivably, the ENUM NAPTR resource records could be served from any domain name, not just one under e164.arpa. One could imaging that in the future, instead of giving a nineteenth-century style phone number (the first Strowger automatic phone exchange was installed in New Haven, Connecticut in 1891), you would give out a domain name (“call me at fazal.majid.info“) or something that looks like an email address. But that is not what ENUM offers (today), in part by design.