Today, as part of the launch of Cisco Collaboration 8.0, Cisco is announcing a brand new technology into the marketplace. This technology - Cisco Intercompany Media Engine (IME) - is a revolutionary new technique for solving the open federation problem. IME addresses the issues that have made open federation a challenge. It enables any enterprise or domain - anywhere in the world - to federate openly with every other enterprise that is IME enabled. IME is effortless. IME federation works with the existing phone numbers used by each enterprise. There are no new phone numbers to assign. Users make calls just like they've been making all along, dialing the numbers of their colleagues through click-to-dial, speed-dials, contact lists, or plain old number punching. Yesterday, those calls went over the PSTN. Tomorrow, they'll go over IP. Yesterday, users got just basic voice. Tomorrow, they'll get rich media. IME is self-learning. An enterprise never needs to configure any information about any other enterprise in order to work. Not one shred of information is required - no IP addresses, no phone number prefixes or dialing rules, no certificates, no domain names - nothing - needs to be configured about other enterprises in order to enable federation. IME is distributed. There is no central hub, no central database, no central service provider. Enterprises participate individually, and the collection of enterprises utilizing IME forms a distributed network. That network becomes the platform that delivers open federation. IME is global. It works everywhere in the world. Enterprises from the United States to Europe, from Asia to Africa, and from Canada to Cambodia can participate. IME is secure. Despite the lack of any kind of central authority or central database, it guarantees the integrity and accuracy of the phone number to domain name mappings it provides. It prevents - through either malice or misconfiguration - misrouting of calls or theft of phone numbers. IME prevents spam. IME brings to the table a new form of VoIP spam prevention. This new mechanism is self-automated, and requires no configuration from administrators or end users. Unwanted calls are blocked at the enterprise firewall. There is no "open pinhole". SIP processing at the firewall itself stops unwanted calls dead in their tracks. IME is under enterprise control. The enterprise administrator is in the drivers seat. They can decide which phone numbers participate, and which ones don't. They decide what features are enabled, and which ones aren't. If they want, they can use IME only with specific enterprises, identified just by domain name. They can block IME from working with specific phone number prefixes or country codes. IME is scalable. IME works no matter how many enterprises use it. Whether its one, ten, a thousand, or a hundred thousand enterprises, IME scales all the way up. IME achieves these goals by forming a unique hybrid of three technologies - the PSTN, SIP, and distributed hash tables (DHT) - better known as peer-to-peer networks. Here, the peer-to-peer network runs amongst servers under enterprise control. Peer-to-peer is often associated with illegal file sharing and desktop software. However, that is just one use of this incredibly powerful technology. IME uses it in a different way - a way that is controlled, secure, and enables a scalable solution to the federation problem. Finally, the path to the future I've been painting has arrived. The boundaries between enterprises will be broken down, and the power of collaboration will be fully realized. ... View more

Open federation - the interconnection of different enterprises for real-time communications services - is extremely valuable. It takes the productivity gains enterprises get from collaboration services, and amplifies them by making them work with their business partners. Wideband voice, video, conferencing, voicemail and telephony features all work better when they work between businesses. Achieving this federation isn't easy. It requires tackling some hard problems - phone number routing, security, quality of service and troubleshooting. Many attempts have been made, but none have yet to take off. The first attempt was built right into SIP itself. SIP was designed from the ground up to work inter-domain and inter-enterprise. As long as users are identified by email-style SIP URLs (like sip: joe@example.com ), SIP can can utilize the same kind of technology used by email to connect together different enterprises. Unfortunately, SIP's domain-based federation hasn't really taken off. Most VoIP deployments (though not all) continue to use phone numbers, and this is likely to persist given the huge installed base of the PSTN. Secondly, SIP's built-in federation techniques don't address the security issues inherent in federation. Most enterprises have been fearful to just open firewall pinholes for incoming SIP traffic. SIP's built-in federation doesn't address the QoS or troubleshooting issues either. Given all of this, open domain-based federation is not widely used. Another technology which was developed to address this problem is ENUM. ENUM had a clever idea - the public Domain Name System (DNS) would be populated with phone number to domain name mappings. Anyone could take a phone number - say, +1 (972) 555-1234, look it up in the DNS, and get back the domain name of the organization that owns the number. The problem with ENUM is that it required government and telco cooperation to populate the DNS records. This has been years and years in the making, with little progress so far. Indeed, there is no motivation at all for the telecom service providers to populate the entries. Finally, ENUM tackled just the routing part of the federation problem. Finally, there have been attempts at solving this problem through a variety of private federation and peering networks. These networks are typically closed. They use a variety of technologies to solve the phone number routing problem. Some of them use private ENUM databases, some of them use SIP redirection, and all of them rely on some kind of centrally provisioned database that is run by the federation provider. Some of these federation services run over private IP networks, which helps address the QoS and security issues. As a consequence, these federation networks are typically limited in scope and size. The book is not closed, however. When you have a problem this important, innovative solutions are certain to appear. ... View more

IP-based communications has seen a meteoric rise within the boundaries of the enterprise. The majority of new product sales into enterprises are IP-based gear. Because of this, we are seeing lots of cases where enterprises communicate together, and though each has IP internally, the telephone network drives communications down to the least common denominator – a basic voice call. In order to achieve real improvements in business-to-business productivity – through wideband voice and video combined with better voicemail, conferencing, contact center and telephony features – requires us to break past the landlock of the PSTN, and achieve true open federation. Unfortunately, achieving open federation is no easy task. It 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. Though attempts have been made to define such a global directory, none have succeeded. 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 is another problem. Today, the Internet forms a global interconnection fabric that touches every enterprise. As such, it is a natural vehicle to use for open federation. However, the Internet provides no guarantees on Quality of Service. 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 an operational one – 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? The most important piece of this is to determine who is 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? And so, despite the great benefits of open federation, these four challenges – routing, security, QoS and troubleshooting – stand in the way of realizing it. Perhaps someday soon, these problems will be addressed. ... View more