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.