Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
ENUM has a critical role to play in telephony services convergence. Although many carriers are adopting ENUM there are myths swirling around the confuse newcomers.
In data networks, the domain name system (DNS) is responsible for converting Uniform Resource Locators (URL’s) to IP addresses in order to route data traffic. The ENUM protocol performs a similar essential function of linking E.164 telephone numbers to Universal Resource Identifiers (URIs)—enabling communication services to use traditional phone numbers to set up calls over IP networks.
Unfortunately, there’s a good deal of hype and confusion around ENUM, which might lead carriers to delay ENUM implementations. That delay would be a mistake—ENUM has real value to offer today in VoIP and other environments. So I’ll attempt to dispel the myths and misconceptions about ENUM and its role in convergence.
Taking Aim at ENUM Myths
Here are the more commonly-heard concerns about ENUM.
Myth #1: ENUM won’t be relevant until public ENUM rolls out in major countries
False. Most ENUM implementations today fall within the private and carrier ENUM categories, used for interconnecting islands of services like VoIP and for reducing costs of operations. It is true that public ENUM efforts are hampered by political and regulatory differences between countries worldwide. But, regardless of the fate of public ENUM globally, private and carrier ENUM has an important place inside converged networks today and in the future.
Myth #2: DNS is too slow, or inconsistent in performance, to support ENUM
ENUM performance is critical to call initiation times. Performance in this respect is measured in query latency—the average time it takes an ENUM server to return a result. Query latency must be in the milliseconds, preferably under a millisecond, to meet the call initiation performance standards set by the PSTN. ENUM critics point to Internet DNS latency—in the tens or hundreds of milliseconds—as proof that ENUM is not fast enough.
This issue is easily addressed once one understands the factors contributing to DNS latency. The first factor is the performance of the DNS server delivering local data. Carrier-grade, high-performance ENUM servers, such as those provided by my company Nominum, can provide one millisecond latencies today.
The second factor is the latency required for the local caching DNS server to retrieve authoritative information from the global network. This includes the authoritative servers’ latency as well as the latency introduced by the distance on the network. On the open Internet, this latency is indeed impossible to control. However, many carriers today are deploying ENUM within their networks and replicating authoritative data locally. This approach eliminates the latency introduced by the caching/authoritative split and reduces or even eliminates external network effects. This approach is possible using modern compression technology optimized for ENUM data, capable of storing hundreds of millions of records on a single Linux or Solaris box.
Myth #3: DNS can’t scale to support ENUM
The data volumes for ENUM data can be quite large because ENUM servers hold routing information for subscribers inside and outside networks, potentially worldwide. Additionally, the information used by ENUM—technically stored in Naming Authority Pointer (NAPTR) records—is much longer than traditional DNS records.
It is also true that today’s widely-deployed DNS servers cannot handle the data volumes—tens or hundreds of millions of records—required by ENUM. But this is an implementation issue, not a design issue. Using compression algorithms optimized for ENUM data, specialized ENUM servers can gracefully handle hundreds of millions or even billions of records.
Myth #4: ENUM will be vulnerable to Denial of Service and other attacks
This argument extrapolates from a current weakness in DNS implementations:
DNS servers are vulnerable to Denial of Service attack…
ENUM relies on DNS…
Therefore, ENUM will be vulnerable to DoS attacks.
The logic is a bit simplistic, but the fear behind it is real. We want reliable communications services that cannot easily be disrupted. Attacks and interruptions on the Internet at large are far too common and widely publicized.
One reason that DNS servers today are vulnerable to these attacks is because they are often running “flat out,” unable to handle large spikes in traffic. Using more efficient server software with sufficient performance headroom alleviates the risk. 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. In addition, in private and carrier ENUM implementations, the ENUM servers can easily be configured to only respond to queries from approved calling elements.
Myth #5: ENUM/DNS doesn’t address local number portability (LNP)
False again. ENUM servers can store a copy of the LNP database and keep it constantly updated with data feeds from NeuStar and other data providers. The question of how you divide phone numbers into zones has ramifications for data management, updates and provisioning. On the surface, it seems ENUM implementers have to choose one of two evils: either confront a massive scalability issue by storing each phone number in a separate and individually managed DNS zone, or take on the burden of building a management application that merges phone numbers into a few zones.
Again, there are design approaches to resolve this problem. Nominum’s ENUM server uses the concept of “composite zones.” These virtual zones, created from multiple sources, act like full-featured DNS zones. This approach allows data from multiple zones to be organized and queried easily and efficiently, and solves the problem of how to deal with Local Number Portability without “breaking” the DNS.
Myth #6: ENUM cannot support fast updates
ENUM data undergoes frequent and consistent changes, as subscribers change service levels, providers, or preferences. Many of today’s DNS servers are not able to support high volume of updates gracefully while handling large query volumes.
Again, this concern is relevant to today’s frequently-installed DNS implementations, and not to the ENUM protocol itself. An LNP database of 200 million records in the US typically experiences 300,000 changes a day—an average rate of less than 5 updates/second. There are ENUM-based servers capable of handling thousands of updates per second while serving tens of thousands of queries per second.
Myth #7: ENUM requires too much network bandwidth
ENUM is an essential component of the initial call connection process. Some in telephony feel that, compared with SS7 and other routing mechanisms, ENUM is not an efficient way to perform call routing, as it requires lookups over the network and therefore consumes network bandwidth.
Considered in the context of VoIP traffic, however, the ENUM overhead is negligible. Network lookups for ENUM typically use a single network packet in each direction. Once the call is established, the first second of voice traffic will consume significantly more network bandwidth, and the ENUM traffic pales in comparison. If the network is capable of supporting VoIP traffic, ENUM should not be a problem.
Myth #8: ENUM doesn’t have all the features of SS7 call setup
This actually isn’t a myth. Using ENUM to route traffic on IP networks bypasses the PSTN and its rich Signaling System 7 (SS7) services. Today, it is correct that the ENUM protocol does not have the rich features built into SS7 over the years because ENUM is part of a larger IP subsystem. Many of the SS7 features are actually contained in other network elements.
At the same time, ENUM providers are extending their solutions to support many of these features, including Least Cost Routing, SIP forwarding, presence, follow-me roaming, etc. And, by using IP networks to route calls, you retain all of the additional functionality provided by converged voice/data/media services, which is lost when using the PSTN. If you are looking purely at feature capabilities, ENUM is the better long-term solution, as it supports next-generation communication services like video, multimedia, conferencing, and more.
Summary
When you separate fact from fiction, it is obvious that ENUM has an important role to play in converging networks. These ENUM myths will disappear as this technology is proven in real-world implementations. For now, waiting for the smoke to clear could be a missed opportunity. If you want to reduce the cost of VoIP service delivery, or deploy new, next-generation network services, then ENUM represents a real opportunity for building a long-term, standards-based solution bridging phone numbers and IP networks.
Background: The Many Faces of ENUM
One potential source of confusion, when talking about ENUM, is the variety of ENUM implementations in place today. Quite often, people speaking of ENUM and what it cannot do are really referring to only one of the following:
Public ENUM: This refers to the original vision of ENUM as a global, public directory, with subscriber opt-in capabilities and delegation at the country-code level in the e164.arpa domain. This is also referred to as User ENUM.
Private ENUM: A carrier may use ENUM within its own networks, in the same way DNS is used internally to networks.
Carrier ENUM: Groups of carriers or communication service providers agree to share subscriber information via ENUM in private peering relationships. The carriers themselves control subscriber information, not the individuals. Carrier ENUM is also referred to as Infrastructure ENUM, and is being adopted today to support VoIP peering.
—-
Originally published in Converge! Network Digest
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byCSC
Sponsored byVerisign
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
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 .(JavaScript must be enabled to view this email address) - 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.