UC Insights Logo
UCI Bannner

Other insights into UC>>

A Camel is a Horse Designed by a Committee

by Russell Bennett, UC Insights

November, 2011

Leave a comment

[I have had it in my mind to write this paper for over a year, but I thought that the subject was probably well understood among those deploying UC.  However, several recent articles and forum postings in the UC community have persuaded me that this subject is still not yet well understood.  So here goes…]

A while back I went to the local Porsche dealership for a test drive of their flagship 911 Carrera 4S model.   The car was beautiful – a wonderful piece of automotive engineering with exquisite handling.  But there was just one problem: I had been to the Ferrari dealership the day before and had been convinced by the salesman that there was no engine on earth like the 670hp Ferrari v12 found in the 599 GTO.  The Carrera engine is only 355hp; so I told the Porsche salesman that I wanted to take the Porsche, but with the Ferrari v12 engine in it.   Quite unreasonably (I thought), he declined to take that order.   So I asked him if I bought both the Carrera and the 599 GTO, could I get a custom car shop to put the Ferrari engine in the Porsche for me.  He pointed out the minor detail (in my opinion) that the Carrera was a flat-6 rear engine car and that the 599 GTO was a v12 front engine car, so the integration might be a little trickier than I thought.   Then he totally killed the deal by asserting that if I was successful in my quest for an automotive ‘best of breed’, I would have voided both the Ferrari and the Porsche warranties.   So much for ‘the customer is always right’.  I rushed angrily out of the showroom shouting: “Typical vendor lock-in strategy!   What ever happened to open interoperability?”

Those of you who have read this far have already figured out that the Porsche/Ferrari story is an allegory and that this paper is going to be my attempt at dispelling the notion of ‘Best of Breed’ UC systems ever becoming a reality.  This is not to say that one entire UC system should not interoperate with another at the system level (aka federation).  UC systems should, and eventually will, interoperate with each other: but we aren’t there yet (see my other papers on this topic).  For me, ‘best of breed’ is the even more utopian notion that elements of vendor A should be able to be connected to elements from vendor B in some sort of arbitrary ‘mix and match’ scheme and that it should all work seamlessly as advertised.  Even more ludicrous is the notion that the ‘best of breed’ whole could be greater than the sum of the parts.  Clearly some UC customers don’t agree with me.

Interoperability Motives and Challenges

Before we get into the ‘don’t try this at home’ part of the paper, lets first examine the drivers behind the notion of ‘best of breed’ interop.

A brief history of ‘vendor lock-in’

For many years, PBX vendors have implemented proprietary protocols on their technology with the full expectation that no-one would even try to mix-and-match.  This mindset was a natural outcome of the national PTT monopolies that existed in every country until about 20 years ago.  When deregulation came about, vendor-lock-in became a competitive weapon.  The end result of this was over-priced, proprietary PBX architectures with ‘bundled’ peripherals that hit their design limits about 10 (or maybe 20) years ago.

SIP and other technologies started to emerge around the turn of the millennium, partly as a reaction to this situation and partly as an example of what Joseph Schumpeter called ‘creative destruction’.  Customers were tired of the status quo and hoped that, since SIP was a relatively simple ‘open standard’, all SIP-based equipment would interoperate; freeing them of the tyranny of proprietary technologies.  However, the reality has turned out to be different, as is amusingly depicted in the YouTube video referenced above.

A scary ‘peek under the hood’ of UC

Anyone who cares to take a look at the base SIP spec (RFC 3261) might believe that setting up a voice call is simple.  An example SIP INVITE from that document illustrates Alice from ‘atlanta.com’ calling Bob at ‘biloxi.com’; just 10 lines of http-like, semi-human-readable text appear to make this happen:

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142

What could possibly go wrong?

Well, it turns out that this SIP INVITE is just a simple illustrative example that doesn’t take into account the negotiation of media (i.e. agreeing what codec to use), routing around firewalls and NATS; much less anything to do with security, including encryption, authentication, etc.  A real-life SIP INVITE looks more like this (opens a pdf).  I won’t bother to try to explain this, nor should you try to comprehend it: just get a sense of it.  Much of the ‘gobbledy-gook’ that you see in this SIP INVITE is designed to address the issues listed above.

In fact, the original SIP spec, RFC 2543 was replaced by 5 specs (RFCs 3261-3265) in 2002.  In an attempt to address all the ‘open issues’ around a communications standard for the 21st century, there followed a bewildering array of other SIP specs to get us to where we are today.  A quick count on the IETF site reveals:

  • 209 ratified standards documents making reference to SIP

  • ~86 ‘internet drafts’ documents representing SIP standards works-in-progress

  • 10 different working groups directly related to SIP

This does not include UC-related standards other than SIP, concerned with IP transport, routing, media security, etc.   Addressing these areas probably entails at least as much effort as that being put into the SIP standards.

Why ‘Mix-n-Match’ Interoperability is Unrealistic

If you remain unconvinced that elements of complex systems that are designed to work together cannot be decomposed into a collection of parts that can be reconstructed into some kind of Frankenstein’s monster, then allow me to be more specific.  Since the UC ‘standards’ are neither complete; simple to understand; easy to implement nor universally adopted; there is ample opportunity for non-interoperability at the component level.

Universal adoption

It may come as a surprise to some, but even at the signaling level there is no agreement between vendors on which technology to use.  Many vendors use SIP, however Avaya, Cisco and Google have adopted a completely different technology for at least part of their implementation, i.e. XMPP.  Skype, recently acquired by Microsoft, has a proprietary peer-to-peer technology.  At the media level, the choice of voice and video codecs becomes even more diverse; within data collaboration, every implementation is proprietary.  At the signaling transport layer, there has been a highly partisan battle going on for years over the choice of UDP, TCP and TLS; even though all 3 are mandated in the SIP RFCs.

Standards interpretations

Where vendors can agree on which standard to use, with such complex documents to contend with, this creates opportunities for misinterpretation.  In my 4 years running the Microsoft Open Interoperability Program, I encountered so many comic/tragic standards interpretation issues that I could write a book about it (and probably will someday, but no one will read it).  Just by way of illustration, I will recount one.

The SRTP RFC is very clear about how you encrypt a media stream to ensure security and privacy.  However, we couldn’t get one vendor’s phone to work with our system after a call had been placed ‘on hold’ when the media was encrypted.  On investigation, it turned out that the phone vendor had interpreted the pre-hold and post-hold media as two different sessions.  They sent a second encryption key after the call came off hold; whereas we had assumed that the entire call was all the same session, so we ignored the second key.  Who was right and who was wrong is not the issue, but fixing this cost both parties a lot of time and money.

Interoperability challenges become almost insurmountable with technology that has already been deployed on customer site, particularly when the issue is embedded in hardware.  Often, the only option is to get the customer to upgrade to a newer system; with a fallback of offering some kind of gateway solution.

The lowest-common-denominator user experience

It goes without saying that all UC vendors spend vast fortunes trying to ensure that their system is better than their competitors.   Doing so means creating features and value that their competitors don’t have; by definition, this means extending beyond the existing standards.  Not only do engineers work feverishly on their underlying innovations, but there are also designers who work just as hard on the ‘look and feel’ of the product.  They obsess over the usability and the feedback that the product provides to the user; the color and placement of every pixel in a user interface; the tactile aspects of the product and the way that it interacts will all the other components of the system.  The next time you meet a group of Porsche designers, ask them what they think of my Porsche/Ferrari idea; I am sure that they will have an opinion.

The technology industry does not innovate in standards bodies purely because that would mean that their innovations would become public property.  Instead, innovations that ultimately provide vendors with a competitive edge (and are not protected by patents) are generally adopted and are later incorporated into standards.  So compliance with standards could not possibly result in a ‘state of the art’ integration.  At best it means that the lowest common denominator level of functionality may work, but that everything else will be broken.  With an IP phone from vendor A that is connected to a UC system from vendor B, it may mean that the phone will make and receive calls, but the ‘message waiting lamp’, ‘missed call alert’ and all other functions (and not just the disjoint set functions) will probably be broken.

Bi-lateral vs. multi-lateral interop

The lowest common denominator issue can only be addressed by two companies working together on a joint design, which may take anywhere from one to three years to complete.  While some UC vendors develop a 3rd party vendor ecosystem, others insist that you buy only their products in order that they can retain control of the ‘user experience’.   The latter strategy is easier to implement and it is a model that seems to work well for Apple, but maybe their ‘PR’ people are better than those of the UC vendors.

By and large, bi-lateral interoperability exercises (i.e. A interoperates with B) are how 3rd party vendor ecosystems are created.  Imagine how much harder it would be to build ‘any-to-any’ interoperability into a system, especially when the other vendor is an unknown quantity (i.e. new vendors, new products, new versions, new innovations).  Then consider the fact that some vendors have consciously chosen not to work within an ecosystem or participate in other interoperability exercises.

This is the impossible premise that belies the ‘best of breed’ notion.


There are many good reasons why ‘best of breed’ integration is never going to work and how it will actually result in the opposite of the desired effect.  No UC system is perfect, but the late (and great) Steve Jobs is quoted as saying:

“Experts can tell you what is wrong with your product, but they cannot make a great one”.

If you can’t find the perfect UC system that gives you everything you liked about your old PBX as well as all the cool new UC features, just pick the one that is best able to address the needs of the future, not the needs of the past.  Don’t listen to this or that salesman who will try to say “OK, maybe our presence server doesn’t scale beyond 1,000 users, but our boss/secretary feature is best in class”: few bosses have secretaries these days.   Don’t be sent on a best-of-breed ‘death march’ just because a few people can’t pick up their own phone.

As a parting semi-humorous/semi-serious quip I will just remind you that, at the end of the book, Dr. Frankenstein was dead, but his monster lived on in torment, seeking its own death.

If you liked this article, please comment, share and/or rate it below.   If you didn't like it, please comment!

Comments powered by Disqus+