Last week Amir Zmora, VP Marketing of our Technology Business Unit and a good friend, posted over at Tsahi’s blog his take-away from the webinar he and I hosted a couple of weeks ago titled “Making Real-time Video Work Over the Internet” (available here for review, in case you missed it).

I think that Amir explained well what we had in mind when we set out to prepare the webinar – explain how technology can overcome the impairments of unmanaged networks, and help us maintain a high level of experience even when quality of service (QoS) is not guaranteed.

And this is not theoretical – Just three weeks ago we launched SCOPIA V7.5, the latest version of our video conferencing solution, and one of the highlights was an enhanced array of technologies for maintaining a high quality experience over unmanaged networks, deployed across our product line, assuring that customers can enjoy a great experience even when network conditions are problematic.

One of the key technologies Amir and I discussed in the webinar, and which is a key element in our SCOPIA V7.5 release, is called NetSense, and as I was very busy in the last year developing it I would very much like to discuss it here in some details.

In the webinar we asked the distinguished attendees what are the main challenges for using the Internet as infrastructure for real-time video calling:

As you can see, most answered bandwidth. And while I’ll be the first to state that there’s no such thing as too much bandwidth, as high definition video consumes a lot of it, it’s not always the case of “insufficient bandwidth” but a case of a dynamic amount of bandwidth.

A Dynamic Amount of Bandwidth

For instance, consider the case of an employee connecting from his home office to a video call with a colleague. This employee has enough bandwidth for the call, and so the quality is great. But during the call, his e-mail client is synchronizing with the server in headquarters. Or maybe his kid is watching a YouTube clip or uploading photos to his Facebook account from another computer. In any case, the total bandwidth will not be reduced, but quality will be significantly harmed, especially if the video call will try to maintain the same bitrate as before.

In general, the case where a video call is trying to “push” more bandwidth than what’s available in the network is called congestion. What will happen is that, in bottlenecks along the line, packets will be accumulated (as they can’t go through fast enough), and eventually be dropped. This will result in packet loss, and we all know what packet loss means for video quality.

Congestion control algorithms, found in most video calling products, deal with congestion by reacting to the packet loss it causes. When packet loss is recognized in the receiving end, the sender will lower the bitrate. However, these solutions are only partial:

• The packets that were lost introduce a dramatic drop in video quality.
• The way to fix the drop is by requesting a key frame (known as Video Fast Update, or VFU), which also introduces a visible artifact.
• The Source of packet loss is not always congestion, and therefore reducing the bitrate as a result will not solve the problem in some cases.

Introducing: NetSense

This is where NetSense comes to play. NetSense is a bandwidth estimation and adaptation algorithm designed with unmanaged networks in mind, specifically the public Internet. It was designed to deal with real-time video calling, and so it complies with the domain it operates in.

Video streams are made up of video frames, each comprised of a set of packets. Video streams also have a strongly obeyed structure (known as GOP or Group Of Pictures), and different frames in the GOP have different significance. Any viable solution must take all that into consideration.

Furthermore, and most importantly, video calling is very standardized in nature. It relies completely on existing protocols that strictly define the communication between sender and receiver. For an algorithm to be vendor and protocol agnostic it has to comply with these standards, and RADVISION takes interoperability very seriously, as you well know.

Standard protocols well define the communication means between sender and receiver in a video call, be it SIP or H.323. Therefore, they constitute the way commands and feedbacks are sent between sender and receiver in a video call. Flow control commands, designed to alert the sender to change the bandwidth, are sent by the receiver according to these standards, and in most cases the sender does not have any other control mechanism for doing that.

So How Does It Work?

When congestion happens, packets are delayed at the bottleneck before being dropped. NetSense monitors this delay. NetSense’s logic and decisions are executed at the receiver side, which – as its name suggests – senses significant increase or decrease in the delay and reacts accordingly.

This way NetSense can converge to the available bandwidth in a given network path during call setup, but also dynamically adjust to mid-call changes in the available bandwidth. Therefore, it perfectly fits the needs of a video calling system on the public Internet.

Furthermore, NetSense is designed to converge fast, and as close as possible to the effective bandwidth. Therefore, you can utilize the most of the available bandwidth, and this happens quickly and without sacrificing the quality of experience.

Using NetSense means that no matter how much bandwidth you have, and no matter how much this bandwidth changes while you’re in a call, the quality of experience will remain as high as possible. Just take a look at the network scenario below, showing how NetSense (the blue line) is able to follow the available network (red line), and you’ll clearly see how NetSense changes the way people can now use video, and for the better.

We are very proud of NetSense. We will present it in the upcoming Packet Video 2010 conference, as well as in the many demos we are running all over the world. The results, as well as the responses from the field, are truly amazing. NetSense is able to finally make sense of your bandwidth, and let you concentrate on making that call, nothing more.