No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cisco Bursty Telepresence and Overlay Networks

Last week I wrote about the tradeoff between an overlay network and a converged network for carrying telepresence or high-end video conferencing traffic. Sorrell left a comment saying that "Telepresence video networks are challenging because of their low jitter ( But I have heard from a number of folks that this is not true of Cisco Telepresence. Two different (unnamed) WAN service providers whispered in my ear that the burstiness of Cisco Telepresence gives them real problems. I found an online white paper where they make it sound like a feature:

Furthermore, video transmission in particular is not "well behaved." It is bursty, even by data standards, and very sensitive to dropped packets. Cisco TelePresence is no exception. Packet sizes and rates vary with the amount of motion in the video image, and, when it is transmitting, the application requires from 5 to 15 Mbps into each meeting room, depending on the number of sites, plasma screens, and pixels per screen.

I think Cisco is the exception. I have not had the opportunity to capture a Cisco Telepresence trace (if you have, send me an email!). I have looked at many traces from Polycom and Tandberg endpoints, and there is no such burstiness in evidence. They have very well-behaved video streams. Why the difference?

I suspect it has to do with history and experience. The traditional video conferencing vendors come from a legacy of working with ISDN, where a fixed bandwidth was the norm. A 384K call running on a 384K ISDN circuit has exactly 384Kbps to work with and no more. So the codec designers worked hard to never exceed 384K, but at the same time to take as much advantage of the bandwidth as they could. So the compression algorithms are designed to make a dynamic tradeoff between frame rate (which translates into motion handling) and resolution, and do the best job they can with the available bandwidth.

Cisco may have decided that since their product was intended for an IP network, and an IP network can often manage bursty data, that they would not work so hard on making the codec use bandwidth smoothly, and would instead optimize the image for motion and resolution. This decision may now be causing some blowback. When you run between 10 and 20 Mbps for a single telepresence suite, the network is often configured to handle only as much bandwidth as it needs, and having to support a 50% or higher burst capability adds significant cost.

For those readers who are saying "Well, that's the difference between Telepresence and traditional video conferencing," I will point out that Tandberg, Lifesize and Polycom are all offering telepresence suites that provide the same high-end immersive experience as Cisco, using those same high bandwidth connections (about 5 Mbps per screen) but doing so with well-behaved codecs. Oh, and they are all standards compliant as well.