Realize VoIP, November 2010

If you wish to subscribe or see other issues of our newsletter, you are invited to visit our Realize VoIP Newsletter homepage.

You can view this issue in the following languages: English | 中文 | 한국어 | 日本語

In This Issue

• Editor's Note
• Secrets of the Lost Packet
• Handling congestion the NetSense way
• Fighting Corruption With SVC
• Product News and Updates
• Blog Highlights
• Webinars and Events
• In Closing

Editor's Note

By Amir Zmora, VP Marketing & Products

Video is happening and it is happening over the open Internet. If this statement was once considered controversial, today there is no doubt that it is true--simply because it is happening as we speak. We see Skype reporting 40% of their Skype-to-Skype call minutes as video and GigaOm projecting that consumers will make close to 30 billion video calls in 2015.

All this is nice, but anyone who has experienced video communication over the Internet (or even over expensive, managed networks in the enterprise) has also experienced video artifacts.

Given the growth of video, the ability to make real-time video over unmanaged networks work is becoming a must. Sagee Ben-Zedeff and I held a webinar on this topic just a few weeks ago and this newsletter is dedicated to the same interesting and important subject. I'm sure you will enjoy this read.

We Value Your Opinion

We would like to make our newsletter even better, so please share your opinions with us:

• What do you like about the newsletter?
• What do you dislike about it?
• What would you like to see in future issues?

You can let us know simply by replying to the newsletter email you received. You can also contact us through our community contact form.

Secrets of the Lost Packet

By Michael Sasson, Platform Expert

It was a revolution when we moved from circuit-switched telephony and ISDN video networks to packet-switched, all-IP communication. Internet took over services for which it was not designed and we have learned about Quality of Service - the most important factor of the IP network.  When data is represented as a sequence of individual packets that are routed independently, each packet has a fate of its own: we never know whether it will be delayed, corrupted or lost - we simply hope for the receiver to receive it in good shape and on time. There is no dedicated path between the transmitter and the receiver: limited bandwidth, latency, noise, packet loss, duplication and out-of-order packet delivery are all problems that affect real-time media over IP networks.

Packet loss can occur due to a myriad of issues that can be classified in one of two categories:

• Congestion, a situation in which the transmitter tries to send more data than is possible in light of the available bandwidth.
• Corruption, packet losses occur "sporadically" due to the nature of the network (wireless), packet collisions, etc.

Both packet loss due congestion and corruption must be handled adequately to avoid degradation in the video quality and user experience. However, each should be handled in its own way.

Handling Congestion the NetSense Way

By Sagee Ben-Zedeff, Director, New Technologies

Video calling over the Internet is becoming more and more popular. The quality of video in such applications is a major contributor to the overall user experience.

Video quality depends heavily on bandwidth availability. If the network path used is under- or over-utilized, high quality cannot be achieved. Overloaded network paths, where the transmitted bandwidth exceeds the maximum available bandwidth of the path, yield network congestion.

Congestion at routers along the path results in delayed packets and even in packets being dropped in order to solve the bottlenecks along the path. Delay reduces the quality of experience significantly. Packet loss results in visual artifacts that most users perceive as severe, and can render visual communication over the Internet useless.

Congestion-control algorithms found in most video calling products deal with packet loss caused by congestion by lowering the bitrates. However, these algorithms react to packet loss, so that packets that were lost before the bitrate reduction will still introduce a dramatic drop in video quality. For this reason, the majority of these algorithms involve a mechanism for the retransmission of lost packets--which in itself degrades QoS in interactive calls, due to the latency caused by sending feedback from receiver to transmitter and then waiting for the retransmitted data.

One of the main challenges in real-time, interactive video calling, therefore, is to estimate the available bandwidth across a network path accurately, and adapt the bitrate accordingly.

RADVISION's unique bandwidth estimation and adaptation technology, NetSense, combines these two key functionalities into one powerful solution: on one hand, delay detection in real-time, before packet loss occurs; on the other hand, bandwidth adaptation to best fit the characteristics of the path.

NetSense is designed for real-time video calling, and therefore can be used over unmanaged networks. It is based on standard protocols only and works with any video format. Hence, it can be integrated into any standard video calling system.

Compared to algorithms found in competing video calling clients, NetSense does better with regard to various parameters:

• It is delay based and not packet loss based. Therefore, there are no visible artifacts even when congestion occurs, as the system reacts before any packets are dropped at the bottleneck.
• It estimates the effective bitrate more accurately (up to 90% of the actual bitrate).
• It adapts to the estimated bitrate faster, and therefore utilizes most of the available bandwidth to provide the best quality of experience.

You can learn more about NetSense in a recently published RADVISION whitepaper.

Fighting Corruption with SVC

By Tsahi Levent-Levi, Director of Technology and Solution

The beauty of IP networks is their "best effort" mindset. You send data and you simply assume the other side receives it - just like when using good old "snail mail". However, data packets can and will get lost along the way: they will get reordered and might even change due to transmission errors of one kind or another.

These types of corruptions cause packet losses that cannot be anticipated in advance - there is no known recipe that works. For these kinds of problems, you need an error resiliency scheme.

Generally speaking, there are three ways to fight errors when it comes to lost packets:

• You retransmit the data when an error occurs.
• On the receiver side, you try to estimate what was lost and fix it accordingly.
• You send the data in a robust way, adding redundancy to it, so that if something goes wrong the receiver will be able to fix it.

The first way, known as retransmission, is impossible for real-time video as it will take too much time to be relevant. The second way, known as error concealment, is messy and may still yield artifacts. And the third one, redundancy, takes too much bitrate when it comes to video.

The optimal way to deal with packet loss is to try and protect what is important (rather than everything), and to make sure this "protection" allows the receiver to fix any loss that has occurred perfectly.

The first is known as Unequal Error Protection (UEP): you don't protect the entire bitstream in the same way, as this will cost too much in bitrate, but instead you rearrange your sent data in a way that allows you to mark special parts of your stream as more important and protect only these parts. The latter is known as Forward Error Correction (FEC), a family of algorithms that add some redundancy information, enabling perfect reconstruction of any lost data on the receiver side.

Add this to SVC, and you have RADVISION's error-resiliency technique: using temporal scalability, we are able to rearrange the stream in a way that is interoperable with other video streams, but which makes a clear distinction between more important (base) and less important (enhancement) layers. On top of this we add FEC in a dynamic fashion, which allows us to increase or decrease the amount of protection at will, so as only to protect the more important part. This yields only a slight increase in bandwidth (~%10) while providing vast error-resiliency strength, thereby rendering great video quality even at high packet loss rates.

To learn more about our SVC solution and how to fight packet loss due to corruption, please refer to our SVC page, where you can find a live example as well as whitepapers and other resources.

Product News and Updates

The following are new RADVISION product releases:

• We have released the H.323 version 7 Beta. This new version supports version 7 of the standard.
• BEEHD for Desktop is nearing version 2.1 with a new Beta. This version adds support to 64-bit CPUs as well as the H.263 video codec for interoperability purposes.
• SIP Developer Suite version 6.0 GA1 was released. Along with a enhanced set of features, it introduces full support for VoLTE, as well as for Android and iOS operating systems.
• Our SIP Server has introduced version 4 Beta, including significant B2B enhancements.
• ProLab version 6.0 offers improved video quality algorithms as well as added HD video support.
• eVident version 2.5 comes with HD video support.

The new versions above are available to customers under maintenance agreements.

Blog Highlights

Enjoy a quick glance at some recent, interesting blog posts on our blog network:

• Islands: Sagee Ben-Zedeff calls for a unified video calling scheme.
• Fandom: Tsahi Levent-Levi doesn't grok the iPhone versus Android wars.

Here are two more posts that have interested our readers in the past two months:

• Operating systems have changed rapidly in recent years. Here is an analysis of modern operating systems and where we are headed.
• Cisco's new Umi device for home telepresence is out, and with it, Sagee's analysis of personal video systems.

We've had our share of cartoons on our blogs - 10 to be exact. Here's a cartoons recap.

Webinars and Events

Past Webinars

Customer Satisfaction Survey

Your opinion matters to us. If you are (or were) a RADVISION customer of any of our developer tools, we would appreciate if you would complete our Customer Satisfaction Survey. It will only take a few minutes of your time and would help us a great deal. We will be leaving this survey open for you to fill in at your own leisure -- but why wait? Take the survey now.

In Closing

This newsletter aims to be useful to you. If you are not finding any value, tell us how we can improve. For more information from RADVISION, you are invited to follow the links below:

• Read our blogs: http://blog.radvision.com
• Join our community: http://community.radvision.com
• Follow us on twitter: http://twitter.com/radvision

Thanks for reading our newsletter!

RADVISION's Community Team

http://www.radvision.com