Archives for 2011

What is TelePresence?

May 20, 2011 by Greger Wedel

What is TelePresence? And what is the difference from video conferencing? This is a topic I have wanted to cover for quite some time…

Let’s have a look at the history first: First there were video calls. Video calls were point to point calls, plain, simple Star Trek calls with one commander on each bridge, typically a call with the commander on a hostile ship. This never took off, because very often more than two people needed to participate. Voila, video conferencing was created! Strangely enough, when video calls again started to happen (“I’ll call you on video”), only the consumer side referred to video calls, the enterprise video conferencing industry was still “video conferencing”…

Well, video conferencing had a reputation as hard to use and with low quality, and Cisco managed to create a new category called “TelePresence” that was clearly differentiated from the old “video conferencing” category. Video conferencing had a bad reputation for not working because you had to add 15 minutes to your meetings to make sure the technology worked before you could start the meeting, and bad networks and things that seemed like black magic had an impact on quality to such an extent that you would have to give up and call each other on a phone instead.

At the time, the people who came up with the “TelePresence” idea belonged to a competitor (I worked for Tandberg), but they got our respect for being able to bring to market a value that was quality assured end to end. “One Button To Push”, a functionality that allowed a scheduled meeting to be launched with the press of a single button, was central to the concept of TelePresence as something that, as opposed to video conferencing, worked every time and where a high-end experience with full size torsos and multiple screens created a user experience that was superior to the tile/thumbnail-based “see-everybody-at-once” video conferencing experience.

Fast forward and Cisco bought Tandberg. Not because the concept of TelePresence had failed, but rather because that was not everything that customers demanded. TelePresence was expensive and ensuring a no-compromise, high-quality experience had a cost. And visual communication is about seeing the person you are communicating with, not only in a boardroom situation, but in any situation where seeing how you react is important (like that hostile commander). Thus, if the price point only is good for the board room or executive, you need to find other solutions elsewhere and that was something Cisco didn’t have before it bought Tandberg.

So, how is TelePresence defined now? Not in a very simple or intuitive way, if you ask me. Wainhouse defines“telepresence” as an immersive room experience with multiple screens (and probably multiple codecs to enable multiple video streams at the same time), and Wainhouse thus keeps some of the previous (read: old Cisco) definition of TelePresence, just removing the capital T and P. However, quite early in the Cisco-Tandberg integration process, we were told that everything we did was now TelePresence. Over night, an executive decision (not quite sure where it was made and how explicit it was) made all the old Tandberg video conferencing systems into TelePresence. I now work in the TelePresence Technology Group, so I guess that’s what we do… No matter how a video system is deployed, even on 512Kbit/s from a home office, it’s TelePresence. Mind you, this wasn’t particularly useful for customers. I mean, one day you have deployed video conferencing in your company, the next day you have TelePresence?!

We effectively undermined the original Cisco TelePresence value proposition as something different from video conferencing. However, internally, it made sense, because by including all the old Cisco TelePresence and old Tandberg video conferencing into the new TelePresence definition, the Voice Technology Group (VTG) can be defined as making UC phones (or video phones). So, these are not TelePresence systems,but they are not really video conferencing systems either, as the rest of the industry continues to make video conferencing systems. Thus, we end up with three different types of video systems: TelePresence, video conferencing, and UC phones.

Well, among customers, we continue to talk about these three categories, because it makes sense, so in reality, executive decision or not, the TelePresence Technology Group not only makes telepresence systems (in the Wainhouse sense), but also video conferencing systems (in the classic sense).

I like “TelePresence”, it’s a great term, it feels like something that is different from consumer-grade video calls and the old video conferencing category. And we know that the resolution, the audio quality, the size of the screen, and the consistent quality of the experience make such a big difference. I don’t think immersive rooms and multiple codecs etc are good indicators of whether a video experience is telepresence or old video conferencing, there are other, non-technical qualities that really make the difference. Can you get a telepresence experience on 24” single screen? I believe so, but is it then just another word for an improved video conference? We don’t believe in limiting visual communications to conferencing, we believe that video will become an integral part of a high-quality experience of personal interaction where you can collaborate almost as being there. Sounds like marketing BS maybe, but to us, that is TelePresence!

My guess is that you will see a trend towards “video calls” or “video communication” as referring to all types of real-time video calls and conferences. You don’t ask your friend if you should audio conference later today when it’s just the two of you. And real-time video is at the core of the experience no matter what type of video system you use. And btw, while useful today, telepresence as a category separate from video conferencing is probably going to be less and less useful. Meanwhile, Cisco TelePresence is what you should look for to get that high-quality end to end experience that you could only take for granted if you were a star ship commander in Star Trek.

RTCWEB initiative @ IETF – video client in the browser, what’s the deal?

April 29, 2011 by Greger Wedel

At the recent IETF meeting in Prague, one of the hot areas was the RTCWEB stuff. The short explanation (Real-Time Communication over the web) is that the browser should become a full audio/video client. The browser needs to get access to hardware and OS resources so a full, high-quality video client can run live inside the browser. This is of course something that Google (Google Talk) and Skype are very interested in enabling.

There are two technical areas that are of particular interest (skip to the last paragraph if you are not too technically inclined…). The first is the interface between the audio/video (RTC) client running in the browser (probably downloaded as part of a web site in the form of Javascript or Java) and the browser itself. An RTC client must be able to request audio and video from the browser (and the browser must know how to access microphone and camera in the OS), but more importantly, for this to scale, the browser must be able to set up an audio/video session directly with another browser (the other person you are calling). The reason is that the alternative, going through a server on the Internet, is costly. The current browser security model only allows a direct connection to the server where you downloaded the web page containing the Java/Javascript, so an important part of the work will be to figure out how to solve this without introducing security issues. It seems that everybody agrees that the browser’s interface (API) used by the Javascript/Java RTC client should be standardized to allow a single RTC client implementation to run on many different browsers. This would allow you to write one RTC client embedded in a web page and it will run in many browsers. Specifying such an API is within the W3C organization’s domain and the W3C is involved in the RTCWEB work.

More controversial, the second interface makes for more interesting discussions and possibly strategic consequences. The RTC client running inside the browser needs to communicate with a server or network to make and receive calls. It needs to register somewhere, “here I am, I’m ready to receive calls!” and it needs to be able to make calls, “please connect me with the following address!” The question is: Should this interface be standardized or should the RTC client just communicate with the central server using a proprietary protocol? The argument for the latter is that it will stimulate innovation and that the above API and how to set up the browser-to-browser media sessions are the only elements that should be standardized. Well, it is likely that mechanisms like ICE may be of use in setting up a session, and there will be media parameters etc that must be communicated as part of setting up a session, so what has already been solved using SIP must be mapped into the protocol between the RTC client and the server that connects the calls, whether it is proprietary or not. Although I’m favorable to the argument that using SIP between the RTC client and the server creates a lot of overhead if you only need a small part for your application, it seems a bit unnecessary that every RTC client implementer has to come up with a new way of setting up a session and exchanging the necessary parameters.

At a higher level, though, what if a Javascript RTC client can leverage a full SIP stack in the browser? Doesn’t that mean that any high-school student could add additional value on top instead of writing a lot of low-level client/server code? If that functionality is not available, both client and server-side code must be developed before the RTC capabilities of the browser can be used. On the other hand, in order to use a SIP stack in the browser, you would need a SIP service running on your server. If you don’t have SIP in the browser, you have to invent your own client-server protocol and you could use simple XML-based exchanges from the Javascript client to your server to set up a session.

Pondering this a bit I get the feeling that no standardization of the RTC client-server interface would spur innovation for small, light-weight applications, but that any real audio/video/IM client implementation would require quite a bit of work to get right. This in reality favors larger vendors with lots of resources. As you probably can choose to adopt a light-weight client/server protocol even if there is a full SIP stack in the browser (or at least, it should be possible to design in way that this is possible), I don’t really see the downside (beyond standardization body cycles) of standardizing how SIP should work between a browser and a web server, probably over port 443/80.

So, what are the consequences for companies like Cisco? We would really welcome video capabilities within the browser. For example, our PrecisionUSB camera would be possible to use to get a high-quality video source. Of course, having a large install base, we would like to ensure compatibility with existing SIP systems and avoid interoperability through a gateway. Gateways are always expensive (especially media gateways) and reduces the functionality that can flow over the gateway. I would love to see the possibility of creating a browser-based client, but if the quality ends up as a least common denominator (i.e. not possible to add codecs to improve quality or extend beyond APIs/protocols to improve functionality), I feel we haven’t gained much. Indeed, enabling a basic real-time communication experience through free services would be beneficial to everybody, but if we do it in a way that allows high-school students as well as large corporations to innovate on top of it, I believe we have much more to gain.

TIP – TelePresence Interoperability Protocol from a standards-perspective

February 19, 2011 by Greger Wedel

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.

Is “standards-based” just a marketing buzzword?

January 15, 2011 by Greger Wedel

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?