If the economics were taken out of question--if you really could do high-quality videoconferencing for near the price of phone conferencing--the discussion quickly changes to one of user preferences and the value of actually seeing each other. We'll leave that discussion for another time.
Depending on who you talk to, the economics of video conferencing is changing radically. The latest evidence of this is Vidyo's announcement Tuesday that it has certified its "video router" (what others call an MCU--more on that in a bit) to run in a virtual machine. Vidyo says it will release products using the new capability in 2012, and that these will mostly be aimed at service providers and large enterprises. The virtualized capability is an interesting one for Vidyo and, while I haven't seen the actual products the company will release, I think there may well be a significant play for it with enterprises of all sizes.
[ Learn more. Check out our report on Enterprise Video: A Viable Option? ]
Exactly what impact Vidyo's announcement will have on the market depends on a lot of variables, including such wildcards as how the company packages and deploys the new technology and how industry giants like Cisco, Microsoft, and Polycom evolve their strategies.
It's likely that many of you aren't familiar with Vidyo, but for those of you who are familiar, and who've sat through an evangelical presentation by the company, you know that the company is convinced it has a better way to do videoconferencing. At least at an architectural level, they in fact do have a better way. If that sounds like a damning of architectures of the big guys like Cisco and Polycom, then good, because that's how I mean it.
If you could start with clean slate and design a videoconferencing protocol, how would it work? Here are some likely design goals. First, you'd want to support a lot of different end points with lots of different capabilities--some will have dedicated large screen video, while others will run the video in windows on laptops or even mobile devices. You'd want to be able to simultaneously support end points with lots bandwidth as well as those on Wi-Fi, cable modems, and DSL lines, and even those on 3G wireless connections.
You'd start by recognizing that with the possible exception of a few phones, end points, with their dual core ARM/Xeon level CPUs, have all the horsepower you'd want to do complex video encoding. If you could, you'd encode the video just once, and do it in such a way that you'd never have to decode and encode it again. Once the video is encoded, you'd want a device at the network layer that knew about the various end points, and that send them the appropriate data stream for their device. This would be largely a routing function, and a matter of selecting the right stuff from the high quality encoding stream that was appropriate for each end point.