Difference #1 in a long series

There was a recent public post by a member of Tandberg's team on one of the video conferencing forums. A lot of people that read my blog also below to some of the VTC forums out there...so you might have seen it.

While I respect their opinion and of course they are both entitled to have it and to express it, I certainly don't agree with it.

And I'll tell you why...

Building out a VTC solution is not based on one factor... MCU horsepower. While Codian did do one good thing for the industry... and yes, I'm giving them kudos right now... they forced the market place (TAA, Radvision, and Polycom) to look at their mcu designs and simplify how mcu capacity is calculated. I'll agree.. the Polycom MGC was difficult to calculate how many people you could connect to it. Thank you Codian. You made us all sit up, take notice, and fix an issue we had.

But..we now have all moved on.. but Codian (now part of Tandberg) beats the same drum over and over. Guys, you are now hurting the industry and hurting customers. Instead of us focusing on customer problems and delivery solutions... we have to spend time talking about ports. And, for those that read the post they made, we actually are able to find lots of faults with your MCU. But...before I get into that... I will not dispute you have a "port is a port" design and I won't disput you built a mcu that has horsepower.

But...what I will dispute is that you have any depth of features to take VTC to the next level. Seeing that you haven't stopped to listen to customers deeper needs, you've missed the boat. Lets start to review those features. I'll try to post one as often as I can when I'm not stuck in a plane.

The first feature is Auto-Cascade. Auto-Cascade is a wonderful feature pioneered by Polycom for customers with geographically dispersed MCUs. Lets go through an example. A customer puts a MCU in NYC, London, and Mumbai. With auto-cascade turned on, if an end user wants to start up an ad-hoc call, all they have to do is inform the participants (email, IM, calendar, etc) to dial into their meeting room, lets say its 5678. Instead of having to call a central bridge, they call their local bridge, enter in meeting room id 5678. The system will automatically figure out that there is say 2 callers in meeting room 5678, one on the London bridge, and two on the Mumbai bridge. The system will cascade the bridges together. No scheduling is needed. No pre-definitions are needed. The cascade link is built automatically based on people being in the same meeting room. This feature makes the end user experience very easy...and it saves tremendously on network costs.

We even have the ability to define how the cascade is made (ip or isdn) and can even define primary vs. backup.

Far as I can tell, best Codian can do is have to manually setup the cascade for every call.

Answer on Cisco TP gateway

I just got back the official word from within Cisco. They do not support setting up a mulitscreen TP3000 to Polycom RPX or Polycom TPX using their telepresence gateway. I was also told that they do not have it on the roadmap at all right now. So... for now, Cisco's solution continues to be a shut world.

BTW... no surprise... the Polycom RPX and TPX systems can call Tandbergs telepresence solution.

Question for all of you on Telepresence

Just in the middle of a customer presentation on RPX... the customer just came over from a demo at Cisco.

Cisco told them that their gateway now supports interop between Telepresence systems...for example from a RPX to a Cisco 3000. They couldn't demo it though....

Have any of you out there heard about this and can comment?

Extra thought on network utilization

One additional point I wanted to make on the below post is that with the great amount of deployment of VTC for work @ home applications...there is a lot of advantage to the asymetrical approach of HD multipoint. For example, my home office internet access is 5mb down and 1mb up. With the approach of sending 4SIF to the bridge and receiving back 720p, makes a ton of sense. In fact with just 1mb up, I really can only send 768K because of the 20% overhead of TCPIP...it puts me at 920k. So, without this great feature, I wouldn't be able to take advantage of HD at my home office. Reduced upload is extrememly common on the majority of home internet plans.

Network Savvy

One things I've been meaning to point out for a while in this blog...and an email I got today reminded me that I need to... was to talk about a key criteria for picking out a High Definition MCU. And that is, how smart is your MCU when it comes to bandwidth utilization. Lets look at two different ways to do it.

One way to do it is to have every endpoint send a 720P image to the MCU. Then, because a lot of people want a CP layout, the MCU has to take that 720p image and reduce it in size to be able to stitch it into new picture that is also 720P to send back out to everyone. So, for example, four endpoints send the MCU 921,600 pixels of information. Say, we've chosen a Quad split. (probably the most popular layout) We have to take 4 x 921,600 pixels and compress it down to just one 921,600 pixel picture to send back to everyone.

Another way would be for the MCU to request each endpoint to send less than 921,600 pixels. The next most popular resolution would be 4SIF or 704x480 or 337,920. pixels. With a smaller image being sent, the MCU doesn't have to spend compute time compressing the picture down to fit into one composite 720p image.

Both ways are applicable, but only one of them is network efficient. In the first example four endpoints each send 921,600 pixels...or a total of 3,686,400 pixels. We only need 921,600 to send out, so, tremdousely oversimplifying things, the mcu has to throw out 2,764,800 pixels... or essentially 75% of the information sent to it. In the second example, four endpoints send 337,920 pixels each for a total of 1,351,680...only oversending 430,080 pixels.

Even though bandwidth has gotten cheaper, I know that all network managers would certainly pick option 2, because it would reduce up to 75% of my inbound traffic to the MCU. Outbound would stay the same in both scenarios.

So, which MCU is smart enough to reduce network utilization? and which MCU doesn't needlessly have to shrink down 720p images down to 4SIF images? Only one, Polycom. Our main competitor Codian, takes the Mack truck approach of wasting lots of resources... while Polycom takes the Toyota Prius approach of using what resources are needed. I think most people would pick the more elegant, more network friendly approach.

Something to make you smile....

One of the cool things about the VTC market is that there are so many feel good projects one gets involved with. VTC really does change lives for the better. I just love this picture...

They new father was in Iraq while the mother was in the very rural town of Kearney, NE.