Emancipation of Telecommunication

Telecommunication through phones and VoIP is not progressing at the pace that it could have. The worlds of the Internet and Telecom do not seem to mix naturally. This article discusses a technology named ENUM that could have solved this if it hadn't been introduced as it was. But it is not beyond repair.

The promise of ENUM

ENUM is a standardised method of using phone numbers in DNS, which is the central name resolution part of the Internet. With DNSSEC, the resolution of names is even verifiable.

The idea of ENUM is to attach Internet services to a phone number, just as you like. Pretty much like you can do with a domain name, basically. A few ideas?

• Add a (reverse) directory server where people can lookup further contact information when they receive a phone number. This may send them the number user's name, perhaps their geolocation and whatever else the number user cares to share. This information is public, and could for example be retrieved when someone receives a phone call, even before answering the call. Just imagine the reduced hassle of exchanging business cards and keeping them updated!

• Deploy servers that offer standard protocols like SIP for telephony or XMPP for chat, and refer to them from a phone number. It would even be possible to define inputs to the chat system for classical SMS and MMS submitters. The servers can be run under your control, so you can control the privacy policies applied to it. And because ENUM is a standard, there is no dependency on any service provider to connect users of different hosting providers.

These facilities enable modes of operation that are similar to the classical telecom constructs, but with the greatly improved flexibility of Internet protocols. And there is no reason to stick to current usecases for phone numbers, because ENUM basically defines a similar name structure to domain names.

The introduction of ENUM

When ENUM was introduced, nobody was using it. This may sound trivial, but in fact this need not be the case if you treat it like a normal domain name. What has been done however, is define rather specialistic technology for it, using special NAPTR records in DNS that are not commonly used with normal domain names. And these records need to be defined in registries that were specially defined for ENUM. This is not a problem when it is popular, but when it is not, nobody cares to update these registers when new protocols are updated.

And ENUM never was popular. No wonder either -- if you introduce something new you need to create a critical mass to get it accepted, and this is notoriously hard. The network effect works negatively in this case; both a client and server would need to support it before it can be useful, so if 1% of the people adopt a technology then only 0.01% of the interactions will use the new technology.

If anything helps to avoid the formation of critical mass, then it is what was done with ENUM: separated technology, sufficiently difficult implementation sides to make developers defer it until others had taken the bait, and a cost to get started.

The introduction of ENUM was fraught with mistakes, and it is no wonder that the popularity of it has stagnated after a few early adoptors set it up.

Still, there are places where it is popular. Confined environments that have adopted it to serve a specific purpose. Countries that use it to grant phone users control over the telco that answers their calls, for example. This helps those users, but also the telco's, that usually prefer to call out over the Internet. Another success story is the non-official ENUM deployment that connects universities all over the World.

The technical side of ENUM

Technically, ENUM is an international phone number written in reverse, with a dot between each digit, and a standard suffix .e164.arpa attached. For example, the international phone number +123456789 would translate to 9.8.7.6.5.4.3.2.1.e164.arpa Users who pass through a mild check of phone number ownership can get hold of such a domain name and post information as under any domain name.

The specialist records that were defined for ENUM include things like

NAPTR 40 10 "u" "E2U+sms:mailto" "!^.*$!mailto:mms@example.com!" .

This is the standard way to direct SMS to an email account. Note how processing it involves handling a regular expression (although that has been simplified recently) and a lot of funny patterns and flags, including ones that setup for recursive handling of NAPTR records. The NAPTR have been defined for domains as well, but are not normally used. What is used are simpler definitions through SRV records that point to servers for a named service:

SRV   40 10 5090 sip.callfilter.net.

The simplicity of processing this sort of reference is widely accepted; but the NAPTR is avoided, probably for its complexity. Still, it is good to realise that something is available for linkage with telecoms infrastructure, even if the real uses of ENUM probably lie with communication over the Internet, using the phone number as an identifier.

Another round for ENUM -- it is not too late

With the benefit of hindsight, one might say that the introduction of ENUM has been a little too pompous. Had it been just another form of domain name, without all these specialist technology issues, then it would have linked in with the existing developments for domain names. And it could have been a light-weight mechanism with easy entrance.

What is needed to treat phone numbers as domain names, is to interpret phone numbers in places where server- or hostnames are expected. So, the only thing a communications app would need to know is that something entered is a phone number and how to rewrite it. After that, it's just a name as any other. It's the responsibility of the ENUM entry in DNS to mention the right information.

Some places don't use a hostname but a user@hostname construction. In such cases, it is possible to use the phone number without the + as a user account name. So +123456789 would translate to 123456789@9.8.7.6.5.4.3.2.1.e164.arpa -- and be handled just like joe@example.com.

In these approaches, some luxoury is possible, but not strictly required; an app aware of the local dial plan could recognise local numbers and translate them to the international format and further handle them like such phone numbers are.

A last entry form is that of URLs. In those cases, it is possible to interpret URIs like tel:+123456789 and make sense of them with approaches as given above.

To help it being bootstrapped, the ideal is to provide ENUM for free. This is perhaps the most challenging part of it, as a bit of infrastructure is needed to maintain it. Still, given that a registry is operated it does not even need to add much; it may in fact be information that is taken from WHOIS records already kept; it would then be a free extra on top of a domain name.

Verified phone numbers take more effort, but can also be provided with a stronger sense of security. Specifically, a DNSSEC signature could be added for such numbers, thus showing to the outside world that it can be trusted. This might be used as an added value, for some payment. Apps that are security-aware would validate DNSSEC and skip unsigned numbers, while others might not care. Validation procedures should probably leave room for appeal, and for withdrawal of disconnected numbers.

What we at ARPA2 are willing to do is to add phone numbers as a syntactically more pleasing way of entry for domain names. Such entries would be an online identity like any other, and could be configured with users, groups, roles and communities. And with subdomains, including single-digit subdomains that would act like elongated phone numbers. So if you needed your family to be directly reachable with a personal number, that'd be possible.

There is a lot of room for emancipation of telephony, and ENUM is the one way of doing it. The approach taken so far has failed, but there is much more that can be achieved, if we do it right this time.