Thursday, March 5, 2009

Collaboration tools for education

Last week, a discussion about collaboration tools for education started in the Megaconference distribution list ( and I felt compelled to jump in. Here is a summary of the key points I made - this for the people who are not on the Megaconference distribution list.

Hundreds of collaboration tools are flooding the market, and usually offer some form of video support. Unfortunately, new market entrants do not seem to care about standards - they support neither H.323 nor the alternative SIP standard, both of which are very well established in the communication and collaboration world. Usually when new entrants introduce proprietary products, they justify it with 'immaturity of standards' and 'time to market', i.e. 'if I had waited for a standard to come out, I would have been late'. These excuses do not work in this particular space because both H.323 and SIP have been around for quite a while and give developers options to implement simpler or more complex collaboration scenarios. H.323 and SIP are also international standards - H.323 is defined by ITU, SIP by IETF - and are therefore supported around the world. The sole purpose of introducing proprietary products is therefore creating islands in the communication and collaboration world. This is a bad idea for any type of organization but is especially bad for education which thrives on exchanging ideas across countries and continents.

There are several options for collaboration software that is standard compliant. RadVision has a product called Scopia Desktop; the soft client is downloaded from RadVision’s Scopia conference server (also called video bridge or MCU) and all video and content sharing goes through the Scopia conference server. While the soft client is free, organizations have to buy more of the Scopia conference servers to support desktop video deployments. All calls, including point-to-point calls go through the server. Since point-to-point calls in the IP world usually go directly between client A and client B, to assure highest possible quality, I have been thinking quite a lot about RadVision’s approach, and the only explanation for it I can come up with is that they just do not know how to sell software and feel comfortable selling more hardware (Scopia servers) to make up for the free clients. Anyway, the business model is very strange, and I really do not want my point-to-point calls to go through any conference server, create traffic loops in the network, and decrease my video quality. (Later in 2009, RadVision released Scopia V7 which supports direct point-to-point calls between clients without going through the Scopia conference server.)

As already discussed in my previous blog posting, Vidyo is trying something new with their SVC technology (the SVC technology itself is not new; it has been around of many years but nobody implemented it). Although SVC is an annex to the H.323 standard now, this does not change the fact that SVC is not compatible with standard H.323 networks (neither is it compatible with SIP). Therefore, connecting Vidyo/SVC system to the H.323 or SIP network requires media gateways, and media gateways do two things: introduce delay and decrease video quality.

Polycom CMA Desktop and Tandberg Movi are standard compliant collaboration products which differ from RadVision because they allow endpoints to communicate directly, and not always call through a conference server. Both products do not require media gateways between desktop video and video conferencing (telepresence) rooms. Both vendors charge for soft client licenses.

In the technology though, Tandberg and Polycom went in different directions. Tandberg decided to base Movi on SIP and leave its video conferencing equipment on H.323. The result is signaling gateways (VCS), and the issue with any signaling gateway is scalability. The scalability impact is not as bad as with media gateways but supporting two protocols simultaneously still decreases scalability maybe by factor of 10, e.g. if you can scale to 50,000 users on a single protocol server, you will scale to 5,000 if the server supports two protocols and has to translate between them. I wrote about this issue on page 3 of my white paper 'Scalable Infrastructure for Distributed Video' (see link in the section ‘White papers and articles’ below).

The Polycom approach is to stick to the H.323 protocol, so that CMA Desktop clients can connect to H.323 endpoints (new and old), to H.323 conference servers (new and old), and support features like H.239 content sharing, continuous presence, etc. Due to its single protocol architecture, CMA can scale and provide the highest audio and video quality between video endpoints and CMA Desktop soft clients.

Finally, a common problem for education is that collaboration tools like the ones discussed above do not run on Mac OS and only support Windows OS. I participate in a lot of events in education and the number of Mac users seems to have exploded. However, Mac is still not getting much penetration in corporations and government (also big video users), and vendors have tough time gauging the importance of the requirement. Thanks to distribution list like Megaconference, we get feedback from education organizations and improve product capabilities.


  1. Stefan: for Mac, try Xmeeting ( for H.323. It is not capable of H.239 but can send slides as video.

  2. [trackback] ...across the blogosphere, fellow blogger and industry member, Stefan Karapetkov from Polycom, wrote a similar piece, following a discussion in the Megaconference mailing list...

  3. Stefan: Your point about TANDBERG Movi being SIP while our videoconferencing systems are H.323 isn't correct. All TANDBERG H.323 endpoints support a dual stack H.323/SIP implementation and both are enabled at the same time. So, in a pure SIP deployment there are no 'scalability' issues as you put it. Having the flexibility to translate SIP to H.323 in the network without the use of very expensive MCU ports (how PLCM would do it) is an additional benefit of a TANDBERG solution, not a drawback.