The Impact of ENUM on VOIP

Being able to translate good old telephone numbers into IP addresses and vice versa might not sound like a big deal, but ENUM, the upcoming technology that enables this, is destined to become extremely important to the rollout of next-generation services in converged multiservice networks.

The issue is that, as networks converge on all-IP infrastructures, service routing becomes far more complex and begins to bump up against the limitations of the well tried Internet Domain Name System (DNS). Although DNS has scaled and performed very well to meet the needs of a fairly limited set of Internet applications, it handles only tens of millions of domain names and relies on a fair degree of end-user tolerance for its seemingly inevitable occasional lapses.

But the future will be very different. Converged networks already support communications among a wide range of different types of device (such as computers, telephones, mobile phones, and PDAs) and applications (such as voice, instant messaging, gaming, and video). In a world where there are already 3 billion telephone numbers alone, the scale of IP domain-name resolution in a fully converged environment will be colossal.

Further, such new mass-market applications bring with them high expectations for service quality, so high-performance, high-reliability name-resolution services will therefore be necessary, and ENUM is the standard that has emerged for carrier-grade converged name resolution.

ENUM does have its skeptics, however. After all, no one can deny that VOIP has managed to gain a significant share of the voice market without needing a specially designed directory service. But this is a little ingenuous, as, typically, calls between VOIP endpoints have been routed over the PSTN, and this can not only adversely affect the voice quality, but also incur call charges. Relying on the PSTN for call routing has been useful for the short term, but it does seriously compromise the low-cost, enhanced-services model that makes VOIP attractive in the first place.

But the benefits of ENUM to operators and service providers look pretty solid. These include:

This report aims to explain some of the whys and wherefores of ENUM, and looks at steps that service providers can take to prepare for the opportunities ENUM presents. Here’s a hyperlinked contents list:

Webinar

This report is based on a Webinar, The Impact of ENUM on VOIP Services, moderated by Simon Hill, Events Editor, Light Reading, and sponsored by Neustar Inc. (NYSE: NSR). An archive of the Webinar may be viewed free of charge by clicking here.Related Webinar archives:

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Next Page: ENUM Basics

Formally, ENUM is a schema that correlates a telephone number to a domain name, which can then be resolved to an IP address (URI) for call routing for VOIP or another IP service. As nothing is simple in next-generation networks (NGNs), ENUM comes in three different varieties: public, private, and carrier.

Public ENUM

Public ENUM has an end-user focus and uses the reserved “e164.arpa” root domain. "Public" here means open to all service providers. Number definition is administered by the International Telecommunication Union (ITU) , which is responsible for country code assignment, and by national governments, which are responsible for E164 number assignment within their country codes. So, crucially, the ENUM database has government oversight and public administration, although end users have the ability to manage their own phone number information and the associated IP addresses. Figure 1 shows the basic setup.

Public ENUM thus requires a formal tiering structure (running down from the root to the Tier 2 providers) and may eventually be regulated or mandated, like Local Number Portability (LNP). Because it is a public system and open to all service providers, there are obviously considerable privacy and security concerns over the access to subscriber information, and users must opt in for their numbers to be entered into the ENUM database.

The elements required to handle the opt-in aspect of public ENUM are shown in Figure 1 as the Registrant, the Registrar, and the Authentication & Validation functions.Private ENUM

Private ENUM is essentially a closed-user-group application of ENUM done for the benefit of a specific enterprise, or trading community or suchlike. So "private" here means that access to record information is controlled by the organization that owns and manages the database. Of course, individual carriers can use private ENUM just for their own benefit, and Figure 2 shows how two IP service providers, A and B, do so to set up calls both within, and between, their respective networks.

Crucially, unlike public ENUM, private ENUM does not require a formal tiering structure, and is not subject to standardization or regulation. Generally, private ENUM is a simpler solution than public ENUM, and currently many providers and carriers believe that their peering and security needs are much better served by using private (and carrier) ENUM solutions.

However, including service providers within a private ENUM community leads to some blurring of the distinction between private and carrier ENUM (see following), and it may be better to view private ENUM as being wholly within an organization’s own environment. When multiple organizations are involved, but are not limited to a carrier community, it might be better to view the situation as a community or federation ENUM implementation. The Internet Engineering Task Force (IETF) currently defines a federation as:

Carrier ENUM

Carrier ENUM is also referred to as provider ENUM in the U.S., infrastructure ENUM in Europe, and operator ENUM by the GSM Association (GSMA) . "Carrier" here means that it is a private ENUM solution that can be used between carriers for peering agreements.

So carrier ENUM enables service providers to place inter-network routing address information in a common DNS, which also does not use the e164.arpa domain name. It is used between VOIP-enabled service providers to discover and exchange routing information and interconnect devices.

The carrier of record manages ENUM mapping of customers’ phone numbers to network interconnection points in a designated DNS domain. For carriers and providers, the great advantages of carrier ENUM are that end-user consent or opt-in is not required, peering arrangements can be very tightly controlled, and there are consequently fewer security issues.

Next Page: ENUM Realities

In practical use, ENUM systems have to meet some fairly severe market requirements, including:

These are much more complex than the requirements on the more familiar DNS, where, for example, there are far fewer zones (.com, .org, .net...) and it is not necessary to take security precautions against such malicious actions as cache poisoning, where unpleasant people tamper with the contents of DNS resolver caches to invisibly redirect traffic to their own nefarious versions of apparently genuine Websites (often of a financial nature).

“As we move to an IP infrastructure, there is concern with the public ENUM approach that would open up telephony to the same kind of problems that we see with email, spam, and so on,” says Dennis Brouwer, Senior Director of IP Services, NeuStar. “I don’t think that we want that experience in our voice communications or other critical applications.”

A further practical issue is that, although ENUM is specified by the 3rd Generation Partnership Project (3GPP) to be part of the NGN IMS services architecture to provide the necessary routing information, no details are given on how that data is to be provisioned. So such key issues as data organization, the logic for optimized routing, and the interconnection of the PSTN with islands of IMS, VOIP, and other NGN services, are left open.

Next Page: The Real ENUM

Because ENUM (especially public ENUM) is complicated and raises many practical issues, current VOIP providers satisfactorily using SIP-based routing information may wonder why they should bother with ENUM. According to NeuStar’s Brouwer, however, this is to miss the point.

“ENUM isn’t about VOIP, a technology choice, or even IP,” he says. “It’s about services, interoperability, and giving greater control to service providers and end users through the use of policy.”

So ENUM gives a method of supporting and controlling multiple services across multiple networks and end-user devices.

“One of the things that has come through loud and clear as we have worked on this in the last couple of years is that it is not about IP, it’s about interoperability. First, of course, between IP networks, but then also, just as importantly, between IP networks and the traditional telephony network, and vice versa."

Further, Table 1 emphasizes the major shift that has occurred in telephony over the past 10 years or so, following the advent of capabilities such as number portability and mobility. A telephone number is no longer a route to a specific copper loop off a specific central office – and hence to a specific telephone. Today it is just an identifier that can be used to locate individuals or services on the network.

Table 1: How the Meaning of Dialing a Telephone Number Has Changed Over Time

Table 1 also shows that services are becoming much more context-aware, and this gives ENUM and SIP a broader importance – both for the network operator or service provider and for the end user.

“This is no longer about a static network, either from an IP perspective or from a telephony perspective. It’s really about a very dynamic scenario and environment both from the operator’s and user’s perspectives,” says Brouwer.

For the network operator, apart from the obvious needs for full mobility, and service and device awareness for interoperability, context-aware services mean being able to operate in a way that merges both competition and cooperation through the use of rules-based policies. That is, service providers will have to cooperate with their competitors in order to be able to establish service routing, but in a dynamic way, and subject to appropriate business policies to control the terms on which they will exchange that traffic with competitors.

This is in contrast with the traditional approach, using first-generation VOIP exchanges in a basically static environment, where all traffic is handed off to a centralized exchange for forwarding. Instead, the move will be to linked-in models, where a service provider invites specific partners to join its network. In turn, partners can make policy decisions about the richness of the information that they are prepared to share – for example, just simple contact information, or perhaps to support a closer business relationship.

And policies will govern the details of different responses to queries based on definable criteria, such as:

For end users a similar evolution to a rules-based policy-aware situation can be supported for service use. For example:

Of course, such refinements can become popular only if there is a very easy way (read GUI? voice-activated commands?) for end users to set the necessary rules. Those with long memories may remember that the Advanced Intelligent Network was going to do all this for the PSTN years ago, but no one could be bothered to learn the long series of keystrokes needed to set up even the crude conditional call handling then on offer.

Intersection of Policy & Services

Overall, policy capabilities are essential to making a multiservice environment available to a broad group of service providers, and to providing a wide set of services to a very diversified group of end users. Brouwer argues that this can be best viewed as a grid, in which different sets representing policies and services intersect, as shown in Figure 3.

Services are represented as running horizontally from the service provider to the end user, while policies run vertically across all services. Note that a source of complexity is that services can be directed to multiple devices that have significant overlaps in their capabilities. The two policy columns to the left (End User Policy and Presence) are the concern of the end user. Each end user should be able to set, either dynamically or reactively, policy that will control for each individual or groups of individuals how they will be contacted and what application they will be using.

Similarly, the policy columns to the left (Network Policy and Interoperability) are the concern of the service provider, and cover such matters as peering and interconnection with the PSTN.

In the middle is the shared column that handles access control. This is very closely identified with identity, and handles the responsibility of the service provider to provide an identity infrastructure to control access to applications, individuals, and other resources on the network. This access and identity infrastructure is available also to end users through their own policy capabilities so that they can control access to themselves and to their services and resources.

Next Page: Next-Gen IP Services Exchanges

A big point of ENUM is that it forms a building block for future IP services exchanges. As already noted, the first-generation VOIP exchanges used today are essentially static, centralized systems, based on the idea that peering service providers dump their traffic on a single third-party infrastructure that acts as a central hub for traffic exchange. Typically, service providers used dedicated, owned facilities to reach the exchange hub, there is little or no policy control, and voice is the only IP service handled.

An ENUM-enabled next-generation IP services exchange is very different. Most obviously, it handles a very wide range of IP-based services, not just VOIP. But topologically, it would exist within the global IP infrastructure and would include a definitive IP services registry to be able to discover routes across the global IP infrastructure. So service providers would peer directly through the global IP infrastructure to enable an individual end user to use a single telephone number to access multiple services on demand, worldwide.

“The challenge is to provide all this at a carrier-grade level that deals with portability in real time, mobility as consumers go on the move, and the constant challenge of interoperability between and among networks across this dynamic infrastructure,” says NeuStar’s Brouwer.

Figure 4 shows a very simplified view of the service-delivery architecture underlying such a next-generation exchange. It is a best-of-breed approach, using a tight integration with existing public databases – the Number Portability Administration Center (NPAC, lower right) for the number portability database, and also the North American Numbering Plan Administration (NANPA), a number-pooling database. There is a significant policy capability in the upper right, as shown by the Policy Engine.

In essence, there is a mechanism to place data – the IP routing data – into the system and a couple of different mechanisms for obtaining that information back out of the system, as required.An operator uses the Publish Interface to input data through the GUI (upper left), and uses it to associate telephone numbers with specific IP address information that is available either from its own internal network systems or from public databases. Business rules are then applied to that data, which is then provisioned into the core engine and the registry itself.

When a call needs to be completed or a session initiated, the information can be queried in a two different ways. For larger operators it is very common to have an operational requirement to download the registry information into a local cache to create a local replica, and then to distribute that cache between and among nodes within the network. This is done through the Subscribe Interface, and its use requires that the operator has invested in its own name servers and associated infrastructure, and has the necessary internal technical expertise.

The alternative approach is to use the Query Interface. This is done directly from the operator’s softswitches on a case-by-case basis, using ENUM (or SIP), and clearly does not require the financial or technical investment that use of the Subscribe Interface does.

“This is an overall architecture that enables an operator to use its existing provisioning methods, to associate IP routing information with telephone numbers, and then to access that in several different ways, depending on their individual service requirements,” says Brouwer. "This is something that will scale and meets the requirements for handling portability and mobility."

Next Page: ENUM in Action

Figure 5 shows an existing application of a private ENUM for MMS that NeuStar has been running for North American mobile operators for the last few years. Currently, it handles over 200 million transactions per month.

This MMS application is very straightforward, as it involves only a single lookup in the ENUM database to obtain the destination URI from the dialed telephone number. More complicated is the way the same system is evolving to handle voice or video calls, as Figure 6 shows.The call originates from the handset on the left. The softswitch is responsible for finding the destination on the network, and it queries the NeuStar SIP-IX database, which provides both ENUM and SIP registry functions. Based on the response, the call is directed via an IP services exchange (IXP) to a border gateway or session border controller (SBC). The SBC in turn queries the SIP-IX database again to obtain an internal route in network B, and the call is routed to its destination.

It is important to note that that the call bearer path across the bottom of Figure 6 (shown by the big extended M-shape formed by the arrows: handset – Softswitch A – IXP Location – SBC – Softswitch B – handset) does not pass through the registry (or even go anywhere near it). So the operator has total control over where that bearer traffic will flow, and the registry operator (in this case, NeuStar) is not involved in that at all.

Further, this is a very basic instance of policy, in that the two network operators have decided not to share full routing information with each other. Hence, as the call that originates in network A is going to a competitor, it is routed to the session border controller first via the IXP, and network operator A does not know the details of the further onward routing within network B that is obtained from the SIP-IX by the network-B SBC. So policy is used to provide a different response to the same query, depending on which operator originated the query and where it came from.

Brouwer points out that the SBC SIP-IX database lookup does not have to use ENUM – SIP Invite is supported – but that NeuStar’s experience is that ENUM scales better. As a general point, flow provisioning can be set up with other protocols, such as XML, but ENUM and SIP are preferred.