ENUM was developed as a set of IETF specifications to enable the Internet community to translate telephone numbers (PSTN addresses) into Internet addresses. When you hear people talking about “public ENUM,” this is what they mean. It was hoped that ENUM would be a catalyst for allowing IP services addressed by telephone numbers — such as VoIP, MMS and video conferencing — to be delivered between users globally, just as the PSTN can deliver circuit-switched phone calls anywhere in the world.
Further, ENUM was seen as necessary to ensure that end users using PSTN and VoIP phones could talk to one another, thus maintaining a global voice community during a period of convergence. Based on what Public ENUM was conceived to do, it’s very possible that it may remain a useful model for an open, egalitarian and user-centric communications system in which “endpoints” rule.
However, end users generally don’t give a hoot about ENUM, VoIP or anything else that we “tech types” in the industry spend inordinate amounts of time thinking about and planning for. The consumer only cares about two things: whether they can reach anyone (and, increasingly, any service too) anywhere at any time via phone, and whether it’s going to cost them a reasonable amount to do so. (We’ve seen evidence of this in countries that have rolled out public ENUM to lukewarm receptions. Clearly, the old maxim “build it and they will come” doesn’t apply to public ENUM, at least not at present.)
In parallel, carriers, service providers, content providers and emerging new business entities face major connectivity challenges as they try to roll out new services. As a result, many industry insiders have analyzed the possibility of using what some term “private ENUM” or “carrier/operator ENUM” technology to assist with interconnectivity. If the problem was actually the same as for end users, this use of the term ENUM would be benign, but in fact it leads to lots of confusion, as we shall see. So, to be clear, this article is NOT about “public ENUM.”
It’s easy to see why some players — especially emerging VoIP-based service providers — are so interested in a “private” version of ENUM: They simply want to avoid PSTN charges. Whenever they can complete a voice call without traversing the PSTN, they shield their business models from the economics of the PSTN environment for call termination. Whereas a single service provider in a single region can realistically accomplish this without ENUM technology or any of its constituent parts, things can become a bit more unwieldy as soon as scale becomes an issue — and this is where ENUM technology can be of best use. ENUM technology can facilitate the linking of disparate network “islands,” and is imperative when customers are seeking to interconnect using phone numbers.
Interestingly, and perhaps surprisingly, the market in which ENUM technology has been most commonly deployed is to support mobile picture phone services (MMS) between mobile operators. This is because within the United States, MMS was the first carrier-launched native IP multimedia service for which phone numbers were used as addresses — and local number portability made it difficult to properly identify the address of a cooperating carrier’s multimedia service center, or MMSC. (Those unfamiliar with wireless can think of an MMSC as a “softswitch” for picture phone services.) ENUM technology was particularly useful in this instance, because it provided a pragmatic way to reuse existing telephone number data. NeuStar has been operating such a service for Tier 1 mobile operators since late 2003, and there are other similar services in the market as well. As a testament to its efficiency, it’s been adopted for many SMS services as well.
Addressing v. Routing: Similar, But Not The Same
Addressing and routing are often lumped together in discussions about ENUM. Addressing is the primary focus of ENUM technology and is arguably the foundation for network and service interoperability, but defining its role in IP is a bit more challenging.
With the advent of a multi-service IP environment, telephone numbers have gone from static port addresses on a switch to versatile “subscriber tokens” for a variety of services including MMS, SMS, Instant Messaging, Push-to-Talk and presence. In this scenario, ENUM technology can make the difference in identifying the service for which the number is being used. ENUM reliably answers the question “what network element address must I use to communicate with the subscriber associated with this number?”
It’s tempting, yet a trap, to assume that as long as you know the “voice carrier of record” for a particular number, you will be able to interface with their border element. That’s because service delivery for subscribers’ IP services are likely to be shared more and more. Going forward, it is reasonable to expect a shared service environment as the norm, and as such, the infrastructure and governance structures the industry creates must be designed to support such an environment. In case anyone thinks this is a pipe dream, we already see Mobile Virtual Network Operators (MVNOs) choosing to operate some services themselves, but relying on their network partner for voice services.
Routing, on the other hand, is the application of policy by a sending network, and it all starts with the ending address of a particular service. In this way, the sender is empowered to apply the business policy of its choosing. Here’s a very rough analogy: I’m a traveler, and I want to fly from New York to Paris. I initiate the transaction by purchasing a ticket from the airline that can fly me to France on the terms most acceptable to me. At this point, I turn over the control of routing policy to the airline, but I have total control to start, because I know the destination. I am not forced to route through that airline; I may choose another, or perhaps I’ll decide to take another mode of transport.
All of this may sound completely obvious, but it is often overlooked when considering the many variables surrounding “private” ENUM. With IP services, the operator of a particular service needs to advertise the address of ingress for that service to its trading partners. And this may be the heart of the matter — provisioning at scale in a multiparty dynamic environment. For the rest of this article, let’s analyze what’s needed from a conceptual standpoint.
The Need For A Shared Registry Infrastructure
Earlier, I described an environment in which many network operators cooperate (and often compete) to fulfill the service expectations of their subscribers. In the case of communication, this expectation is near universal global reach. What is most needed now is a way for every operator to declare to all other operators:
The service the operator provides
The telephone number associated with the service
The address of the network element with which to handshake (e.g., a URI)
Service operators need an environment where, by policy, they can expose only the information they want — and then, only to parties to whom they want to expose it. They argue that unlike public ENUM, this should be a private environment.
As we have seen, a single phone number may have multiple service operators associated with it (e.g., MMS), and the existing regulatory environment ensures that there should be one authoritative answer. This may not be the case with emerging services, so one of the things needed most is a set of agreed-upon rules so that the service declarations that operators make are understood, trustworthy and serve to empower routing policy — and are NOT used to abuse the cooperative nature of the system.
Put another way, we need a multi-service shared registry infrastructure where this information can be cross provisioned — a kind of authoritative “Yellow Pages,” if you will. The Number Portability Database and its surrounding business processes in North America (such as the Number Portability Administration Center, or NPAC) are an early, “pre-IP services” attempt to achieve this kind of dynamic system. As it currently stands, the existing voice addressing infrastructure i s simply inadequate. It may be adaptable — in fact, some in the U.S. have suggested adapting the NPAC to fill the role — but the industry, collectively, will have to decide the right course forward.
From here, the rest of the ecosystem falls into place. In fact, there’s been much work done on this using ENUM technology (and even SIP) as the query/response protocol. There are a number of high-quality ENUM caching servers and services designed to answer queries — a rough analog of SS7 SCPs. Some network elements do not support ENUM yet and must use SIP for now, though ENUM is generally thought to be the more efficient protocol for this.
Separation of Roles
What else can we learn from the NPAC? It seems to work best when the operator of the registry/addressing infrastructure cannot exploit its position, but rather operates in a way to maximize choice and competition in the rest of the ecosystem. With the NPAC, there are authorized users who get neutral and equal access to data. The registry operator does not have any say as to the contents of the database; it simply synchronizes the declared service addresses industry-wide. It cannot “game” the addressing system for its own benefit, or to the benefit of any specific “partner.” Further, it has no special privileges regarding use of the data; in fact, it does not own the data.
Empowered with information, service operators are free to apply their own policy to routing. Should they choose to outsource a route, that partner can use the same destination information to make similar decisions. Notice that in all cases, the router has access to the destination address information, and thus can freely apply policy. The end service operator is the provisioner (what I called the “declarer”) of the service ingress address. This is essential in maintaining the distinction between the addressing and routing roles — and, ultimately, the integrity of the overall system.
Business: Does ENUM mean “free?”
This discussion would be incomplete without mentioning business models. Many argue that the whole point of ENUM is “free termination” or “bill and keep” business models. They may be right — but they may not. Regardless, that is a different part of the interoperability problem and tangential to solving the problem of IP service addressing. It is not the role of an addressing infrastructure to impose inter-party business rules — not now in the PSTN, and not in the future with rich IP services. That’s up to trading partners.
Conclusion
While some think there ought to be a single central database, others contend that there should be a system in which one master database is logically divided into a series of authoritative master databases. Both fall into the category of “registry infrastructure.” Without such a registry infrastructure, we will have many network elements that are ENUM-ready and capable of answering queries — but we will have no assurances that the answers are right or trustworthy. The registry master(s) must be single authoritative databases; some have called this concept “the golden copy.” In other words, with no authoritative registry infrastructure to maintain the integrity of a global addressing scheme, interoperability will be hopelessly inefficient at best, and more likely simply not work very well. I reiterate: Addressing is the foundation for all interoperability and routing.
Steve Granek is Vice President, IP Services, NeuStar, Inc. (news - alert) For more information, visit the company online at http://www.neustar.com.
Do SIP Services depend on the emergence of a global ENUM system?
Answer: SIP and ENUM are often lumped together, but SIP does not technically “need” ENUM. At its most basic, ENUM simply translates phone numbers into IP service addresses; services that are not addressed with phone numbers do not need ENUM. However, it is clear that phone numbers are not going anywhere anytime soon. Even when people choose a name to dial on our mobile phones, the underlying infrastructure uses a phone number — and for someone addressing a service to the IP world from the PSTN world, a telephone number is the only choice.
In addition, services that are NOT SIP-based can also benefit from ENUM; we’ve cited the MMS example as one that already exists. In summary, ENUM and SIP are not codependent. (Having said that, SIP services will be rolled out in a world where services will interoperate between the PSTN and the IP world, and ENUM will certainly ease adoption of SIP services as a result.) IMS standards — all of them — assume the need for an inter-party addressing environment based on ENUM technology.
|
SUBSCRIPTIONS
TMCnet LOGIN
WEBINARS
