A Vendor Driven Federated Exchange?
Last week I saw an interview with David Chavez, Avaya’s CTO of Sales, on NoJitter posted by UC pundit Dave Michels. In that interview, Chavez was promoting his concept of a ‘Federated Exchange’. He defined a Federated Exchange as:
“…a service that securely associates sessions in one domain to sessions in other domains. To make this easy and natural, it provides interworking between SIP dialects and codecs. Additionally, a federated exchange provides a means for controlling reach and visibility of its subscribed users. To address privacy issues, it is inherently opt-in and individually-focused as opposed to enterprise focused. To increase its relevance to the subscribers, it allows them to create additional characteristics about themselves that could be useful to the parties with whom they interact.”
Sounds a lot like NextPlane! Chavez went on to say that SIP wasn’t well suited to achieving inter-vendor interoperability and that IMS (an extension of SIP and real-time communications defined primarily for carrier networks) was the way forward:
“Most vendors have Balkanized SIP with proprietary dialects to overcome that. So everyone can say they are standard and show a list of RFCs they adhere to–everyone. Yet, because of the different extensions, the only interoperability practically achieved is very basic. I think IMS greatly helps and it is a 3GPP standard…”
Since the carriers seem long ago to have lost interest in IMS, and the other UC vendors, as he says, have all gone in other directions (i.e. not the IMS direction) then this appears to be Avaya’s own proprietary, non-interoperable tangent while claiming to be standards compliant. However, that was just the start of the debate. A few days later, NoJitter editor, Eric Krapf, followed up with his own piece called “Federation: The Vision and the Pipe Dream”, in which he said:
“The concern, or the obstacle, I think, is how quickly this can metastasize into a grand vision or God Box that simply becomes unwieldy both from a user standpoint and a market standpoint. Also, if everybody starts building their own version of a Federation Exchange, then pretty soon you almost need another layer of abstraction to connect all of the existing Federation Exchanges.”
Well put Eric! We already have non-interoperable UC systems – what we need is an interoperability layer that is independent of UC vendors and which accommodates the needs of UC customers to communicate with each other. Sounds a lot like NextPlane!
Naturally, Chavez had to respond to the ‘pipe dream’ gibe, and he invited Krapf to support, rather than denigrate, the federated exchange concept. Krapf responded by pointing out that Avaya was already boycotting the Unified Communications Interoperability Forum (see my last post), which says all there is to say about Avaya’s stance on interoperability. Thanks go to Paul McMillan who pointed out in the comments section that a federated exchange was already implemented by NextPlane.
After my musings on inter-vendor interop in my last post, I wondered if there wasn’t already some commentary on why the UC vendors can’t “just play nice”. Sure enough, there was an article, also on NoJitter, last year talking about the Economics of Interoperability. This article shows that, in a competitive environment, interop becomes a competitive weapon and that the theory of network effect actually creates a disincentive, rather than an incentive, for vendors to cooperate. I hadn’t really thought about it that way, but now that I have, it certainly explains a lot.
So my conclusion is that a federated exchange can only be created by an organization that is separate from the competing UC vendors. That exchange has to be like Switzerland: constitutionally neutral; accommodating of all points of view and comfortable speaking multiple languages and dialects.
Just like NextPlane!