Archives for 2011
I have for quite some time wanted to write more specifically about TIP (TelePresence Interoperability Protocol) from a standards point of view. Polycom’s recent announcement on putting TIP on specific products has generated additional interest in the topic, so I think the timing is good 🙂 First, let me just emphasize what is in general true for this blog and also in particular for this post: Although employed by Cisco in the Telepresence Technology Group, I do not represent Cisco in this blog and my opinions are solely my own.
Let me first explain a little bit about the history of TIP before I put it into a bigger context. Cisco (pre-acquisition of Tandberg) looked at the existing video-conferencing market and decided it was room for creating an entirely new market category called TelePresence. TelePresence should fix all the problems that the video-conferencing industry was struggling with that in sum reduced the user experience: underlying network problems, problems of setting up a call, inconsistent user experience in conferences, “old satellite phone call”-feeling in conferences making interaction awkward, lack of full-size representation of the all the people in the meeting room you were talking to and so on. The result was something really stunning: built on top of a quality-assured Cisco network, Cisco TelePresence would consistently deliver an experience for the participants that would wow people and immediately could be used as a boardroom and executive-level collaboration tool. This was really good for the video-conferencing industry because when key decision makers got their eyes up for the business value of interactive video meetings, the interest really picked up in general. Internally in Tandberg people joked about John Chambers being Tandberg best-performing sales person.
However, to deliver such an experience, there was one major trade-off technologically: new innovations had to be made that broke the interoperability with the existing video-conferencing world. In particular, multiple screens and cameras in each room had not been done before and there were no good standards for communicating all those video and audio streams and required information about them, e.g. where they belonged in the other end (i.e. “this screen is the left, this is center” and so on). This lead to a new way of signalling that was proprietary and that would make it impossible for other vendors’ video endpoints to participate in a call. Once this decision was made, a second decision was made: as only CTS systems would be compatible anyway, the full H.264 codec standard didn’t need to be implemented, so quite some time could be saved, thus getting the product to market faster.
Fast forward, Tandberg was bought by Cisco. As part of regulatory approval, Cisco agreed to packet its proprietary method for making multi-screen systems work with each other and not only publish the specification details, but also give away the rights (to IMTC) and commit to implement according to this specification in new products and software releases. The main purpose was to avoid that Cisco’s new (and larger) product portfolio would become a walled garden that could lock out competitors. Thus, Cisco published TIPv6 and then subsequently version 7 of the protocol and handed over the rights to the IMTC.
However, due to the fact that Cisco TelePresence systems had these media restrictions (among a few other things), profile documents (one for single-screen and one for multi-screen) were published by Cisco to ensure that vendors that implemented TIP also could communicate with Cisco TelePresence systems with media restrictions. The fact that there is a separate profile document for single-screen highlights another important thing: single-screen CTS systems also required TIP and adaption to the media restrictions in order to communicate with it. Technically, without the media restrictions, a call can be done within existing standards (SIP), so TIP really shouldn’t be necessary. This confused people a bit, because TIP should only be necessary for multi-screen, but as discussed above, practical considerations in implementation also made TIP necessary in order to communicate with any Cisco TelePresence, also the single-screen systems.
So, where are we now? TIP is being adopted by the industry to facilitate multi-screen interoperability, as seen in Polycom’s announcement. And further improvements to TIP will be done through the IMTC open process. Has Cisco successfully managed to create a de-facto standard? Or as probably competitors would spin it: has Cisco through its market power forced other vendors to implement TIP to solve their customers’ problems created by Cisco in the first place?
Well, I don’t think so. Engineers are never satisfied and even though TIP solved a problem where no standards existed and we now have a standard, it doesn’t mean that the current version of TIP can solve all the problems we want to solve in the future! That is why we are actively contributing our considerable experience in designing, implementing, and supporting a protocol for TelePresence interoperability to the community by pro-actively working together with other vendors in standards-organizations. This commitment is evident in Cisco’s investment in IETF participation (See the CLUE working group) and in the ITU (see the Telepresence question). The focus is not on turning TIP into an IETF or ITU standard, but rather to take the community’s collective experience in multistream video/telepresence and amend existing standards or come up with new additions to the standards-set to support not only today’s successful TelePresence application, but also the innovations we are all working on in the labs.
Readers of this blog have seen some of my thoughts on the trade-offs between innovating and creating real value for customers, while still ensuring interoperability (in particular, in a previous post I covered the challenges with the Tandberg Multiway feature). Also, in a post I did in December last year, I covered why I believe interoperability is critical to creating customer value and that the video-conferencing industry should emulate the open eco-system of the mobile industry as opposed to the closed PBX environments. I know there has been quite a lot of speculation about what would happen when Cisco, with a walled garden implementation of TelePresence, acquired Tandberg, known for its considerable effort in supporting standards and proven interoperability across all products, both own legacy and 3rd party products. Would a combined entity de-focus on standards and prioritize innovation and choose an approach to standards that I in a previous post characterized as “Be inspired by standards and implement something proprietary”?
I will not claim to have the answer to that question, I assume our customer will vote with their wallets based on what we are actually bringing to market, our ability to deliver business-value when our products are deployed today, and based on our credibility in being able to do that in the future.
Internally in engineering, we have declared the following guidelines: “standards-first” and “standards at the core”. The implications of this is that we want to make sure that we always use available standards to solve our engineering challenges and that we should pro-actively ensure that third party products can participate in our solutions to the best of their capabilities. We don’t do this to be nice, but because we truly believe that this is what our customers want as a base level. However, customers also want the extra value we can offer if they standardize on our equipment.
And of course, that is what engineers live and breathe for: create that new, really cool stuff that makes customers want to buy our stuff! So, when we add our “secret sauce”, it is as an upgrade to what can be achieved in a standards-based call (or as extra goodies in a standards-based call), and not as a lock-out by creating artificial walls.
I believe a proof point is what we are doing on the single-screen CTS endpoints (yes, judge us on our actions, not our words): we are removing the media restrictions to make sure that it can interoperate with any H.264 BP system, and we are removing the restriction that the other endpoint must talk TIP to the CTS. The consequence is that any third party endpoint can do a regular standards-based SIP call without loss of functionality.
We all know that most customers hate vendor lock-in. They want the freedom to switch vendors whenever they want. But still, they also want all the features and functionality that vendors can offer them. And if the value is high enough, customers accept being locked in. The iPhone is a good example, the applications you buy on the iPhone cannot be moved to a new Android phone. However, there is a limit to this acceptance: if the SMS and MMS messages from an iPhone could only be read on other iPhones, then people would hesitate buying iPhones unless all their contacts also had iPhones. So, acceptance to being locked in is related to the perceived value it brings.
This is where standards come in. By implementing standards and being very vocal about “our standards-based strategy”, a vendor can make the customer comfortable that lock in is avoided. In reality, most customers are unable to resist the temptation to implement vendor-proprietary functionality (and it is hard to know when that line is crossed), so they instead settle for a compromise where a multi-vendor environment is possible, but where the most value is achieved when a “preferred vendor” is chosen. In the communications world, the word “interoperability” is thus important as the level of interoperability a vendor implements will determine how much value you as a customer can get when you choose not buy from the “preferred vendor” or communicate with somebody else using another vendor. If there was a standard for smileys in text messages and the iPhone did not implement that, but used a proprietary smiley method, well, then you could only use nice-looking smileys to other iPhone users, but they would be unreadable on non-iPhones.
However, there is more to this, in the real world, even within a single vendor, you have several generations of products and these older products may become obsolete quicker or slower dependent on how much focus the vendor has on interoperability. Again using the smiley example, if smileys from an iPhone 4 would look crap on an iPhone 3, the cool smileys are starting to become really useless.
And this is a reality in the video/telepresence world as well. For the customers it is really hard to see all the caveats that come with that new shiny feature. In video, the SVC media encoding/decoding profile is an example where the consequences can be hard to understand. It’s confusing, because SVC is without doubt a standard, but different vendors’ implementation of SVC are not automatically interoperable because the mechanisms required to reach interoperability have not been standardized. So, standard vs non-standard is not even black or white (see this exchange to see how confusing the whole SVC discussion really is).
If I still haven’t lost you, we are starting to get to the core of the standards issue: how vendors execute on their “standards-based strategy” found in their marketing material. In a previous post, I wrote about the Tandberg Multiway feature and the different options we had in trying to get it standardized. I tried to highlight the challenges and dilemmas in trying to increase the value customers get from our products through innovation. When you as an engineer create a new feature, you have the following options:
- Only use standards-based mechanisms and if nothing is available, don’t do it
- To the extent possible use standards-based mechanisms and if nothing is available, make something proprietary
- Be inspired by standards and implement something proprietary
- Just make something that will fix the problem, don’t worry about whether there might be a standard for it
The engineer’s choice is dependent on how clear the strategic direction is: should always standards be used, even if they may not really fit and it would have been easier to just invent something? Once a standard is chosen, can you add your own goodies? And if you do, will your standards-based approach really work with other vendors’ products? Or is it even important? We can still market it as standards-based (true), we just don’t tell what does not work (we haven’t even tested)…
Once you have implemented something new that is not a standard, you may want to make it a standard because management says it is important that we are standards-based. If you did your research, used standards where you could and maybe talked to the people working in standards-organizations, you may, through quite some effort and time, get something very similar to become a standard. Or, you could save some time (if you work for a big company), post it somewhere and call it a standard and hope that it becomes a defacto standard because your company’s market power will force competitors to implement your way of doing it because THEY want their products to interoperate.
However, even if you didn’t do your research, so what you did partially overlaps with existing standards or is done in a way that conflicts with standards, you can STILL post your work as a standard and hope it becomes a defacto standard (if your company is big enough). Note that all these approaches qualifies for using “standards-based” in the marketing material…
To successfully drive a defacto standard, three things need to be true:
- The market muscle of your company must be big enough
- What you are doing has not already been done widely and must be acceptable to other vendors, i.e. they see they can solve some of their problems using your defacto standard
- Customers actually get true value from your implementation and are willing to stay within your closed defacto world (until others adopt it)
Very often, successful defacto standards go through a standardization body and are slightly modified to take into account other related problems that need to be solved and that are important to the industry. But the majority of attempts at creating defacto standards fail.
Which camp do I belong in? I believe my previous posts show my conviction that we as vendors in the video and telepresence industry should pro-actively push the bar higher on what is considered the right level of interoperability. That will give more value to our customers, and I firmly believe that a standards-based strategy is way more than a marketing buzzword, and if your customers believe you and you prove that you execute on it, it will be a clear differentiator because your products offer more value to the customers. It does have a cost for vendors and it is by no means easy. I believe working through standardization bodies is key, however, most often somebody needs to lead, get something done, and then show it to the others. BUT, I do not believe in dreaming up something that is not based on existing standards where possible and then forcing it down the throats of others as a defacto standard.
Are you now able to better understand your vendors’ approach to standards? And as an engineer, do you share this analysis of your options and dilemmas?