A VoIP NNI: The next frontier

AT&T’s recent announcement that it has certified Avaya and Cisco IP PBXs for interoperability with its voice-over-IP services has some huge implications. First, the move officially starts to bridge the gap between VoIP in the LAN and in the WAN, explicitly moving WAN-based VoIP beyond simple toll bypass. Second, it enhances the legitimacy of VoIP and moves the IP PBX in particular and the VoIP market in general from a niche to the mainstream. And it also opens up a world of new “challenges,” to use the common marketing euphemism for problems. (For details on the announcement, see AT&T enhances support for IP PBXs and AT&T’s certification of IP PBXs adds credibility).

The greatest challenge for global voice network interoperability is making the transition from the traditional public switched telephone network (PSTN) to an IP-based network. Today, using the PSTN, you can call anybody, anywhere, anytime. Someday we’ll be there with VoIP services as well, but making that transition as effective and efficient as possible just isn’t here yet.

Let’s take the AT&T VoIP service as an example. Site-to-site calls within a corporation are a piece of cake if you don’t leave the AT&T service. Making all-IP voice calls to a business partner also on the AT&T network, and calling from the AT&T VoIP service to a PSTN location, also are relatively easy.

Unfortunately, that’s where the simplicity ends. What happens if you want to call a business partner who uses MCI, Sprint or some other service provider for his internal network? On the one hand, you could use specialized firewall gear that understands VoIP and use the Internet for transport. But there are numerous other issues, from security to quality of service, involved with using the Internet for this task.

At the other extreme, the call could be handed off to the PSTN for switching and then re-enter the IP realm. However, this is at best a stopgap.

What we need is true service interworking – a Network-to-Network Interface (NNI) for VoIP. And we’ve been here before. In the early days of frame relay and ATM, the networks were VPNs in the truest sense. You had connectivity only to other points on your private network. And it was mandatory for that network to be provided by a single service provider.

Then the Frame Relay Forum developed the frame relay NNI and the ATM Forum developed the InterCarrier Interface to define how traffic could be handed off from one service provider to another. The good news is that the specifications were developed and worked well. The bad news is that even today, the willingness of service providers to implement NNIs is driven more by politics and marketing than by meeting customer needs.

Moving forward, the need for the rapid implementation of NNIs for VoIP is obvious. But for these NNIs to meet the market need, they must be implemented openly and universally, like the Internet’s peering points.