I’ve been dealing with VOIP since Simon Hackett and my company put out the first Etherphones in 1991.  And I have yet to see anyone express an interest in actually using ENUM.

The reason is simple - why should I use a meaningless phone *number* when I can dial by a more easily rembered name?

It’s only the legacy 12-key pad that drives people to use numbers.  And as people get more used to doing texting even that barrier will diminish.  And besides, even those SIP URI’s that I’ve seen tend to look like 12345@example.com - and that requires letters as well as digits.

A large portion of folks in the SIP universe, at least those who aren’t using one of the packaged products, use their email addresses in their SIP URIs.

ENUM is best thought of as DNS on top of DNS - it’s really a new layer of naming that just happens to use DNS to generate URI’s that contain DNS names.  And as a new layer, it effectively doubles the number of DNS queries that occur in the absence of ENUM.

I have particular concern about what will happen when system administrators start playing with ENUM’s regular expressions.  Even technically experienced people are sometimes driven to the brink of madness, or beyond, by regular expressions.

And from what I have seen, national ENUM systems will become simply the directory of last resort.  Most folks who have experimented with ENUM so far (and those folks are hard to find in the SIP community) tend to set up their own local ENUM services so that they get the first crack at resolving the name and optimizing the call routing.

And with facilities such as DUNDI coming along it’s not at all clear that VOIP even needs an ENUM-like centralized directory.

As I see it ENUM will probably become simply a transitory legacy bridging technology.

Interesting article. Two questions.

1. Regarding DDoS attacks, you write:

Also, because the ENUM data itself will be distributed and replicated in many sites rather than clustered in a few authoritative servers, it will be much more difficult to actually disrupt ENUM service with a DoS attack.

Does that translate to “throw more bandwidth at the problem”? And with the newer style of amplified DDoS attacks, is that effective?

2. Who are the players here looking to provide a non-PSTN service (besides your company, I’d assume)? I read recently that VeriSign and Switch/Data are working together — how does that involve ENUM?

Thanks in advance.

How people understand ENUM amazes me, particularly Mr. Auerbach saying “why should I use a meaningless phone *number* when I can dial by a more easily remembered name?”

There are quite a few answers. One will be: just to be polite with the called party

Because ENUM is essentially a called party facility. If the called person has opted to use ENUM she/he will have given you the ENUM number and published (via ENUM NAPTR) his wishes for how the call should be terminated. This might be a single VoIP identifier, but most likely it will be a list of how the call should be forwarded to various fixed-line, cellphones, secretarial or voice mail services. It is the called party choice to opt in ENUM and to decide to let the caller know her/his wishes. If callers fail to follow this, do not blame the industry.

A presence enhanced ENUM facility having various profiles could automatically change the called party wishes as a function of where he/she is available.  This could be a mechanism to automatically switch between cellphone and Voip. But again, if callers fail to follow the called party selection the whole new telephony wouldn’t make sense.

(FYI, until quite recently I was a telecommunications regulator in a well known European country.)

I think you are missing the point - ENUM is only partially about caller control of where a call lands.  The larger part of ENUM about preserving telephone *numbers* and to a degree about preserving the historical, but obsolescent, hegemony of national number registries.

The first point to recognize is that ENUM is based on a mapping of a sequence of PSTN *digits*.  That means that ENUM isn’t even usable for a call-by-name system until the name is translated by some means into a PSTN number.  And given that the evolving systems (such as SIP) are based on URI’s (names) rather than numbers the notion of mapping a called URI to a number so that it can be processed by ENUM to give a URI is the internet equivalent of using an automobile to go from one room of your house to another.

A user does not need ENUM to create a changeable mapping that one can use to send incoming voice calls to a VOIP phone, facsimiles to fax machines, etc.

It is just as easy, and definitely more straightforward, for folks who want to send their incoming calls to the right place, to simply create DNS names for each target or class of targets.

For example, I’d create home-phone.cavebear.com and mobile-phone.cavebear.com as distinct names for my phones, and have a generic name, phone.cavebear.com that maps to all of ‘em.

In fact, right now with SIP, without ENUM, if you call my VOIP number it will ring at my home, my office, and on my laptop.  The call will bind the call to the first one that answers.

ENUM is inefficient - it at least doubles multiple DNS cycles to resolve an ENUM name - first there is the fetch of the NAPTR record, then there is the fetch of a name (or multiple names) from the list of URI’s that result from the NAPTR processing.  Moreover, the kind of changeability of DNS resource records that is envisioned by NAPTR - for example the kind of changes needed to support a “follow me” service based on ENUM - requires that the records have a relatively low TTL value.  That will, in turn, reduce the effectiveness of DNS caches and, in turn, increase DNS transaction rates.

And ENUM does hold a lurking monster - regular expressions.  Regular expressions can be quite difficult to do correctly - entire books have been written on the subject.  I personally expect ill-formed regular expressions in NAPTR records and bad regular expression parsing in calling devices to be a significant cause of ENUM call failure.

In the community of folks who build VOIP gear I don’t see much enthusiasm for ENUM.  It’s treated as just one of those things, like XML formatted logs, that are viewed as present only to satisfy purchasing clerks.

There is, of course, a final issue about ENUM: Whether national ENUM services will be a first source or final source of call resolution.

My own sense leads me to believe that national ENUM systems will, at best, be last-resort sources.  When a user places a call the first resort will be the user’s own call-by-name directory.  Then there may be company or organizational call-by-name and call-by-number directories.  Companies will want these so that they can have some means of routing calls via private intermediaries, such as secure tunnels, and the like.  And then I see arising various private organizations that will use their own private data to map a call.  And only after all of that, and only if the call is in the form of a PSTN number, will a national ENUM be used.

The telco’s just don’t seem to get the point that the new telephone is a computer, OK, Nokia gets it.  And as computers new telephones can engage in interesting forms of dynamic registration with presence servers to announce their locations and also interact with interesting forms of target locating services - there’s no need for an intermediary, national ENUM service.

So, in a kind of recurring childhood, I expect telephony to resume something like its original mode - when you picked up the handset and said “Hello central, could you please give me Fred” and the operator, based on your identity and context resolved your request and made it happen.  With new phones it will be software rather than a human operator and the context search will be vastly more elaborate and extensive.

Mobile telephony, 3G inclusive, is also based on e.164 numbering, although my cellphone allows me to call by name. Also if I shout a name of an acquaintance this precise terminal will recognise whom to call. I wish my next WiFi VoIP phone having that facility

Mr. Auerbach, will you now say I am in favour of inefficient technological solutions such as voice recognition to map my voice to numbers?

Most likely the ENUM caller will also have a User Agent piece of software nice enough to hide URIs and DNS and perhaps numbers, as my cellphone does.

ENUM doesn’t claim to be the most efficient technological solution to user call forwarding forever. But today it is an indirect dialling service that works seamlessly on POTS and VoIP and builds on the great value of the e.164 numbers: millions (or billons) of people knowing how to dial everyday. Most of them are quite illiterate in telephony and VoIp technology internals, and wish to remain so.

I am neither criticizing the efficiency of the design nor comparing it with SIP based solutions, I am just drawing attention to the strong prejudice some technologists have against an indirect dialling procedure which is good enough to facilitate VoIp take-up, at a point in time where VoIp still pre-adolescent. Why is that attitude?  Is there another well-known alternative?

As you have explained, when a user places a call today he has to decide how to establish the call: via VoIp, Fixed-line POTS, cellphone… entering a URI or dialling a number. With indirect dialling it is the called party wishes that matter and solve that decision.

Another benefit of indirect dialling is to free the user to change his phone telco, webpage, IMS, email or whatever telecom service he uses without having to tell all his contacts about that.

ENUM benefit to the user is more about solving a social need than a technological issue. Please don’t miss this point.

Also do not expect ENUM or equivalent methods to be promoted by the traditional telcos. Facilitating lowest cost routing will skim their revenues.