The Challenges of Open Federation

Summer blockbuster days are here, and the top of my list is a screening of the rebooted Star Trek franchise. Star Trek is, at its core, about exploration of the final frontier, and how disparate cultures band together to explore it. In some ways, our industry is in the same place. Our final frontier remains ahead of us, and like Star Trek, it can only be explored by working together. That final frontier is federation, the interconnection of separate organizations to bring end-to-end rich IP communications beyond their respective boundaries.

As we stand on the edge of this new frontier, two paths lie before us. One path open federation allows for true any-to-any interconnection using IP at the core. The other overlay federation relies on a network of SIP providers
to find a SIP-specific path between two organizations. Open federation allows for the kind of innovation that we've seen on the Internet, whereas overlay federation is likely to operate like an SIP version of the existing PSTN.

Achieving open federation despite its advantages over overlay federation still requires overcoming four main technical hurdles: call routing, security, QoS, and fault management (aka troubleshooting).

The call routing problem is a simple one to understand. Given that the vast majority of calls are made to phone numbers, how does one determine a mapping from the number to the domain which owns it? Such a mapping needs to be global, openly available, and contain correct entries. ENUM showed great promise as a solution to this problem. The idea was simple have the carriers populate the public DNS with mappings from phone numbers to IP addresses. But public ENUM hasn't appeared, owing to administrative and business problems. Carriers must insert the data, but what's their incentive? How does a DNS administrator decide if an entry is authorized to be placed into DNS? These problems proved nearly insurmountable, and ENUM is now primarily used by carriers themselves to establish overlay federations.

Security is another challenge in open federation. There are many aspects to this problem, but the biggest by far is how to allow open connectivity while at the same time blocking VoIP Spam and Denial-of-Service attacks. Most organizations
are fearful with good reason of just opening up a port on their firewall that would allow incoming SIP traffic to touch their call agents. What happens if someone sets up a cheap open source PBX on the Internet and starts spam-calling phones? Or what if they use the open pinhole to flood the corporate PBX with SIP traffic, causing it to fall over, disrupting normal voice traffic within the business? These are non-trivial risks. There are other aspects to the security problem. All traffic has to be encrypted as it flows between domains, and all intervening NATs and firewalls need to be traversed.

Quality of Service (QoS) is another problem. Today, the Internet is a natural vehicle to use for open federation. However, the Internet provides no guarantees on QoS. The resulting "best effort" service is often good enough, but business-to-business federation demands something more. How can we achieve open federation with the level of call quality that each individual domain demands?

The final problem is operational when calls transit between domains over the Internet, and things don't work, how does each side of the call learn about the problems, and how are they diagnosed? What's important is to determine who's at fault. Is it the domains themselves? Is it the ISP of one domain or the other? Or was there a quality problem in one of the transit IP networks between? This problem exists in overlay federations as well. The difference, of course, is that in overlay federation, the service providers take responsibility for troubleshooting this. In the open federation model, the service providers only offer transit IP service, and aren't responsible for making sure that any particular application whether it's web, email, IM or voice work.

And so, despite the great benefits of open federation, these four challenges routing, security, QoS and troubleshooting
stand in the way of realizing it. As such, the future is uncertain. As we stand on the final frontier of VoIP, will we boldly go where no man has gone before? Or, will VoIP just be assimilated into the PSTN?