Following my post Are OTT The New Walled Gardens? The organizers of the VoLTE 2011 conference in Paris invited me to speak about this topic in the conference and participate in a panel titled: “IMS: Why Operators Need it for Voice Service in LTE and How Can They Implement it?”

The conference spans different aspects of VoLTE, from the network to value added services. It brings together speakers and delegates from different segments including service providers such as Deutsche Telecom and vendors such as Ericsson, Alcatel-Lucent and Acme Packet. More about the sessions can be found on the agenda.

What will my session focus on?

In my session I will be talking about the coopetition of OTT service providers and “traditional” service providers. OTT is a threat to the incumbent service providers. In the eyes of the service providers, OTT are those that:

• Providing innovative services
• Offering competitive business models, mainly freemium
• Are cool [I can’t put a logical claim behind this but why would someone who practically has an unlimited voice or SMS plan use an OTT service such as Viber or WhatsApp?]

We see cases where service providers team-up with OTTs and officially launch an OTT service over their network. This happens in cases where the service provider is pushed against the wall by a competing service. A good example is the launch of FaceTime by Apple. This has caused service providers to launch an OTT video chat service such as Qik (later acquired by Skype) over their network.

Having said that, the introduction of OTT video service by the service provider is a pain reliever for their pressing problem of customer retention and need for innovative services. Yet, as for voice and SMS where the service provider will always want to maintain these core services under his control, also for video chat, as it becomes popular, the service provider will want to be in control and the one providing the service.

Questions I will address in my presentation include:

• Will the Service Providers become just Network Providers?
• What assets do they hold that will allow them to make the user chose their service vs. a free OTT service?
• What are the differentiators the service provider will be able to offer to the end user to regain their loyalty?
• What are the main drawbacks of OTT services (hint: the title of my presentation)?

We have a discount for you

Want to hear more? Interested in coming to the conference?

We managed to get a special 20% discount for the readers of our Blogs. To claim it, follow this link to RADVISION Blog readers discounted VoLTE 2011 registration page and use the password: azspevolte.

Note: We are not receiving any special benefits from the organizers based on registrations done on this promotional registration discount. We simply want our readers to come and enjoy the conference and if you are planning on coming please drop me a note so we will have a chance to meet.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

While they are doing this using open sourcing these products and providing them to the community, they are keeping a tight leash of control around the focus of these products – just ask Andreas Constantinou about how he thinks Google will be using Motorola and their Android:

“1. In the software dictatorship scenario (which we take as the default option), Google would make it untenable for OEMs not to follow its software specifications to the letter or to fork Android. Google stays true to its core ad business and divests everything apart from patents to a Taiwanese OEM wanting to break into the North America market.”

You can be sure that the second scenario will drive OEMs towards the same goal – it’s a very interesting and recommended read.

The more interesting part, is how Google are actually using these two tools to get an edge over competition. Here are a few examples.

SPDY

Google is all about speed – how fast they can serve their customers with search results and ads. That is at least how Bob Cringely sees it. In a very interesting post about how Google employs Carson’s speed, he notes how Google running hardware in less than maximum CPU speeds to gain the most out of their data centers:

“That would be Carson’s speed — the speed to get the most extra speed for the least extra cost. Or, as Carson put it, of finding “the least wasteful way of wasting.”  For aircraft the speed in question turned out to be 1.32 times the speed for most miles per gallon (the Bruguet Number). Carson’s Speed uses excess power most efficiently.

Other than three G-V’s and one Boeing 767 built for a harem, Google flies data centers, not airplanes. But Google’s situation going into its power experiment was actually very similar to aviation because it was an exercise in reducing power. Google data centers weren’t built to Bruguet specs, they were faster. Given this excess computing power that had already been paid for in capital terms, what was the most efficient way of using it? Carson’s Speed — about 43 percent power — leaving plenty of excess cycles for new services like Instant Search.”

I’d like to take it a step further: as speed is the most essential to Google, when they saw its inefficiencies, decided to do something about it. It wasn’t trying to improve HTTP by aiming for a new version of it, but rather starting from scratch and coming up with a new protocol: SPDY.

And how do you make a new protocol into a standard? With 2 years already for SPDY, it seems like it still isn’t in the IETF in any meaningful way yet. So the next best thing (or the really best thing) for Google was to make it a standard de-facto: their Chrome browser has it implemented already. And if you access any of Google’s web services, Google just might decide to use SPDY instead of HTTP to serve you (which they have started doing).

If up until now, Google used the web and speeding up the web to compete with desktop applications (mainly Microsoft), it is now able of competing directly with any other cloud based company – they are still going to be SPDYer.

And while Chrome isn’t the most used browser (yet), think about mobile now – Android is a large part of the market… where Google’s browser is used by default – and connectivity to Google’s own services on Android are controlled by Google.

WebM

When Google acquired On2 it was for their VP8 video codec. A year down the road, it renamed it as WebM and open sourced it. The next logical step was to add Chrome support to it (and get an ecosystem of companies around it).

The idea was to get rid of the patent payments on the H.264, but I think it was also to control the video parts of the web.

And again – with Chrome, Android and the ecosystem they built around it, they are in a good position to compete with others who are interested in media (think Microsoft and Apple).

WebRTC

WebRTC has a similar story to WebM. Google acquired GIPS, and then took the media engine, wrapped it up with JavaScript, called it WebRTC and pushed it as a kit to be integrated into browsers. This one provides media engine capabilities suitable for voice and video calling over the web from a browser.

As they control Chrome and Android, it can be expected to see WebRTC being integrated into them soon enough, with a clear aim of disrupting the voice and video communication market.

Without Chrome and Android, none of the initiatives above, as well as others that Google are promoting, wouldn’t come to play.

These initiatives are playing a unique role in driving Google’s innovation and competitive edge now. They give away these technologies as open source contributions, which builds an ecosystem and drives adoption. While their competitors can take these technologies just as easily – they will always be playing the game as followers in such a case.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

• Part 1: NetSense 101: Why do we need bandwidth estimation?
• Part 2: NetSense 101: Packet-loss-based Bandwidth Estimation
• Part 3: NetSense 101: Delay-based Bandwidth Estimation
• Part 4: NetSense 101: Q&A (this post)

You should know by now the two techniques of estimating bandwidth: based on packet losses and based on delays (=NetSense). This is what this series is all about.

In this post, I’d like to focus on a few questions I am usually asked about NetSense and provide the answers for them.

Is NetSense interoperable?

Yes it is. Even if only one participant in a video call uses NetSense, there will be an improvement in the experience of the call. In such a case, the person who will enjoy the increased experience will be the one running NetSense – the video he will receive will be of a higher quality.

Do I need to run H.264 or SVC to use NetSense?

No. NetSense doesn’t care about the actual media being sent – it is an algorithm that looks at incoming RTP packets and deduces out of it what the available bandwidth is. How to convey that information and change bitrates in the video encoders is up to the layers on top of NetSense.

Does NetSense work with both audio and video?

NetSense deals with finding available bandwidth from looking at incoming RTP packets. This means it has nothing to do with audio or video directly. We use it for video calls, where NetSense decides on the amount of bandwidth, and then our internal decision making processes will decide how to allocate that bandwidth between the audio, video and data channels of the calls.

I want to reduce bandwidth use. I understood that SVC is what I need. How does that fit with NetSense?

The truth is that SVC increases the bandwidth required for a point-to-point call for the same media quality. SVC is a technology that allows encoding video in layers, and it can be used for increasing the robustness of the video or to build better switching MCUs.

You might be able to use a bandwidth estimation mechanism to decide which layers out of your encoded SVC stream to send, but then – why would you encode all the layers? Better just estimate the bandwidth and tell the encoder dynamically how much bitrate it has available. This is what NetSense does.

Why do I need SVC if I have NetSense then?

The two technologies deal with two separate network problems.

• NetSense deals with congestion: packet loss caused due to too much data being sent
• SVC deals with corruption: packet loss that cannot be solved by reducing bitrate

You need both to get high video quality in all packet loss cases.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

• Part 1: NetSense 101: Why do we need bandwidth estimation?
• Part 2: NetSense 101: Packet-loss-based Bandwidth Estimation
• Part 3: NetSense 101: Delay-based Bandwidth Estimation (this post)
• Part 4: NetSense 101: Q&A

If you just bumped into this post – I suggest you read the first two parts of this series. It all boils down to this:

• We have bandwidth
• It fluctuates in its availability dynamically, each and every second
• We need to know how much of it we have to do video calls
• The most natural way of doing it is looking at packet losses, but this isn’t the best of ways
• If we could know the bandwidth we have / are going to have in a moment, it will allow us to reduce / increase our media’s bitrate and fit it to the network. This means we will have better video quality at a lower latency

How do we achieve that prescient knowledge? Being able to predict what the network is going to be like in the very near future?

We call it NetSense.

NetSense is a technique of sensing the current state of the network and estimating out of it how much effective bandwidth do we have available.

To understand how it works, think about switches and routers for a moment: Network switches have their own internal queues. They receive packets, store them internally for an instant, they decide where to route them next and then they send them out and clear them from their internal queues. If a switch gets too much packets at a given point in time – his internal queues will fill up, and he will start throwing out packets, causing a packet loss (=congestion).

As a thumb rule, the more packets a switch has in its queue, the longer these packets will take to get routed to their next hop, increasing their latency.

And here lies the whole idea of NetSense: it monitors for changes of the delay between media packets that are received, and out of it tries to deduce what happens in the switches along the route of the media. If it finds out that a switch somewhere starts accumulating packets in its internal queues – NetSense will re-estimate available bandwidth and act accordingly – without getting to the point of experiencing packet losses.

Here’s a diagram illustrating how NetSense works – you can compare it for the blueprint provided for the packet loss technique in my previous post.

What do you gain from NetSense?

• Better video experience, as there are no packet losses
• Lower latency, as NetSense tries to reduce congestion on the network

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

• Part 1: NetSense 101: Why do we need bandwidth estimation?
• Part 2: NetSense 101: Packet-loss-based Bandwidth Estimation (this post)
• Part 3: NetSense 101: Delay-based Bandwidth Estimation
• Part 4: NetSense 101: Q&A

Bandwidth. We don’t have enough of it. And video calling devices need to know how much of it is available. That’s at least the gist of what I’ve written in why we need bandwidth estimation.

How do you estimate it today in most cases? Using packet loss information.

When two endpoints are engaged in a video call, they send RTP packets with the actual compressed media in them. In parallel to the RTP, there’s an additional protocol called RTCP that is used. RTCP takes care of sending control information between the endpoints that relates to the RTP media: how many packets were sent, received, lost, etc.

This information can then be used by the sender or the receiver of the media to change his behavior in real time.

In most systems, the decision is left to the receiver – he is the one that receives the data and is aware to some extent on how the link is behaving.

The receiver will be monitoring the incoming media, and if he sees that there are just too many packet losses (a heuristic that is different between vendors), it will estimate how much effective bandwidth it has and from that information ask the sender of that media to reduce the bitrate on one of the media channels. This in turn, will reduce the quality of the encoded data, reduce the frame-rate or the resolution – again, based on the sender’s own internal policies.

The diagram below illustrates the flow the receiver will use for the bandwidth estimation algorithm.

While this is the “industry standard”, there are a few soft spots with this solution that I want to point:

1. The amount of packet loss that causes re-estimation of the available bandwidth is based on a heuristic. It might not be the best one and it might not be able to distinguish between congestion and corruption types of packet losses (we want to focus on congestion with bandwidth estimation).
2. This solution is aggressive. As long as there’s no packet losses (or maybe little), we won’t reduce the bitrate. In a way, this is similar to the bufferbloat problem, where we try to send as much data as possible without taking into consideration the internal queues of all the switches and routers along the way. This in turn can increase the latency of the media.
3. We will reduce bandwidth only after a congestion already occurred and has affected the video quality. This is too late, especially when we will be requesting for I-frames in parallel (=frames which take a lot of bandwidth to encode).
4. The estimated bandwidth we will synchronize on isn’t an accurate one. trying to estimate it from packet losses means we either need to reduce bandwidth aggressively, and then we lose some of the bandwidth that is available for us by the network – or we might need to reduce it more than once to synchronize on the available bandwidth, which will lengthen the time until we get the video quality to a reasonable level yet again.

So you see: there are things we can improve. The main thing being able to “know” the available bandwidth before congestion occurs. While we haven’t yet developed our prophetic module here in RADVISION, we actually did come close when we talk about bandwidth estimation; but this will be the topic of my next post: how do we estimate bandwidth based on network delays.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

• Part 1: NetSense 101: Why do we need bandwidth estimation? (this post)
• Part 2: NetSense 101: Packet-loss-based Bandwidth Estimation
• Part 3: NetSense 101: Delay-based Bandwidth Estimation
• Part 4: NetSense 101: Q&A

We’ve written in the past about bandwidth estimation – in the post I just linked to and elsewhere. But I think it is time for a few more posts, to explain a bit more about the rationale behind our bandwidth estimation mechanism; and this time I plan on starting from the beginning – with the WHY question.

Video is a bandwidth hog. To send video in good quality you need a lot of bandwidth – usually upwards of 1 Mbps. And when video gets encoded before it is being sent, the decision is made about how much bandwidth to invest in each and every outgoing video frame. While we can always invest a lot, the question that becomes: Will the bits I am investing in my encoded video make it safely to their destination?

You might say that having a broadband connection to the internet should be enough for me not to dwell on the issue. But this is untrue – when I am working at home, there are multiple machines connected to the internet on that same connection, each doing its own tasks – passively updating my email inbox, Dropbox, Evernote and other useful cloud accounts, actively having my wife browse her Facebook account and my daughter watching YouTube songs. This means that effectively there’s less bandwidth available for my video call. And as if this is not enough – there are a lot of infrastructure (switches and routers) between me and my destination – infrastructure that caters other bandwidth hog users out there.

This boils down to a simple truth – while video calling requires both low latency and high bandwidth, both will fluctuate in their quality throughout my video call: I’ll have varying bandwidth and different data delays in that 30 minutes call I am having.

It means that my video encoder – that part that takes the raw video from the camera and compresses it before sending it to the network – needs to be flexible enough to change the way it works: increasing and reducing the amount of data it generates based on the current conditions of the network.

What will happen if my video encoder will ignore the network conditions and just continue generating a 1 Mbps bitstream for a network that has only 512 Kbps available? It will simply congest the network, causing packet losses, which in turn will kill any chances of having reasonable video quality until the network conditions improves.

My encoder needs a way to estimate the current network conditions (=estimate the available bandwidth), and from that decide how much bitrate it has and encode accordingly, reducing or increasing quality/resolution/frame rate to achieve that goal.

There are several ways of estimating that bandwidth, where the most common ones are based on packet losses. I’ll touch these techniques in my next post.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Why does it take so much time to add new features? Why is it complex? What’s the big deal with video calling applications? Why should companies just license this technology from others and not develop it on their own?

The best answer I can provide is that video calling requires a lot of disciplines:

• You need a codec expert. Make that two – one for audio codecs and one for video codecs
• You’ll need someone who knows his voice algorithms and how to fine-tune an audio system (not necessarily the same person as the codec one)
• You’ll need someone who knows his video algorithms – one that knows the niche of real-time bidirectional video and not one that knows how to stream video over the internet (these are two distinct disciplines)
• You’ll need someone who is capable of working with DSPs – assuming you’re developing an embedded solution
• There’s this signaling stuff that needs to be handled – another discipline
• Interoperability. Different than just signaling or media or standards
• Some management stuff – SNMP, TR-069, SSH, TFTP or some other acronym that goes there

That’s a lot to chew for something that should be a feature in a product. And I haven’t touched issues of multiplatform support when you need to do tablets, phones and laptops all at once or dealing with user interfaces, hardware design and some other tasks.

While you might license the bits and pieces of the above stuff from various vendors and then integrate them – this comes at a huge cost of needing to have most of these disciplines in your enterprise to be able to do the integration properly.

Next time you think about building an application that requires video calling – may I suggest you license most of it from someone instead of developing on your own? It will let you focus on things that matter – the actual service and the user experience.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

As the need for VoLTE is growing dramatically around the world, developers are spurred to bring implementations to the market rapidly. As a result, standards are not always adhered to and chipset vendors have to endure end user experiences that leave much to be desired in terms of quality. There are heavy investments being made in developing VoLTE handsets. Unlike the global Internet, IMS/LTE networks contain additional embedded control functions geared to provide resource control, security, and QoS on the network. Providing a high level of quality to end users is of critical importance to the new VoLTE service. It is essential for service providers to maintain high quality and to ensure end user satisfaction.

When preparing new real-time voice and video over LTE, service providers must assess whether their network can provide and maintain the expected quality of service (QoS). Service provider administrators must make informed decisions regarding which network devices to deploy, the amount of bandwidth needed, and the optimal network configuration required to support voice and video over LTE technologies and to detect faults that may affect its usage. A proactive approach is needed to ensure VoLTE readiness before deployment on the network, as the success of these services depends on the ability of the network to support them.

End user-experience testing plays a critical and vital role in product development and quality assurance cycles, thereby helping equipment vendors to develop high-end VoLTE services.

What makes VoLTE testing complex and challenging? It is the fact that there are so many parameters to take into consideration, such as audio and video measurements, video telephony including motion level, codecs, IMS/LTE test case simulation with different scenarios that emulate the network the UE and the IMS core part, QoS, and interoperability test cases.

For LTE handset vendors it is important to have a feature testing system for IMS UE applications and IMS servers capable of simulating signaling and media, including end user experience and call features testing.

For IMS core vendors it is important to perform capacity testing, which typically refers to performance metrics and the simulation of thousands of handsets.

Providing a high level of quality can present a considerable challenge. It is vitally important to be able to quickly and reliably pinpoint and resolve quality-related problems as they occur. These issues are exactly at the heart of an upcoming free webinar we’re doing on “Ensuring VoLTE Conformance and User Experience” be sure to register to learn more about VoLTE testing.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

What’s RTCP? It’s a companion protocol to RTP – the one used to send and receive most media over IP these days. It gives it a lightweight control mechanism that provides feedback to the sender about the quality of the data it is sending – how much packets the remote side received, what got lost along the way – this kind of information.

Another use of RTCP is to know when a call can be dropped. In SIP, for example, call control can take place over UDP, where there is no way to know if one of the user agents crashed or dropped out of the network due to some extraneous reasons – especially when the only thing flowing between the user agents is the media. In such a case, monitoring RTCP reports can be used to determine if a call got dropped.

Today, RTCP can do much more. And by much more, I would like to shed light about two interesting IETF RFCs that deal with extensions to RTCP that make it quite an important part of real-time visual communications: RFC 3611 and RFC 4585.

RFC 3611: RTCP-XR (Extended Reports)

RTCP is a kind of a reporting protocol: it collects information and then reports it every once in a while. Problem is – it provides very little information. This often means that you can use it in a limited way to solve issues such as congestion.

To improve what you can achieve with RTCP, RTCP-XR (RFC 3611) was defined. RTCP-XR simply adds a bunch of additional information that can be collected:

• Now you can know not only how many packets were lost, but also what sequence numbers they had – which means that a sender can now try and retransmit them instead of sending a fresh new I-frame if he thinks this improves things.
• Now you can get know the jitter information on the receiver side. Or the MOS value he has for your voice (it’s a measurement of quality)
• Or a bunch of other stuff that may come useful if you want to improve the overall quality of the media.

What are the main additions of it over the basic reporting?

1. Sequence numbers of lost packets
2. Sequence numbers of duplicate packets
3. Packet receipt times
4. Receiver reference time
5. Delay since the last RTCP Receiver Report was received
6. Statistics summary
7. VoIP metrics

The exact use of each is reserved for the applications themselves, but this added information gives a lot of power for optimizing solutions within the scope of the standard in a way that maintains interoperability.

Oh – and if I haven’t mentioned it – RTCP-XR is required by IMS implementations.

RFC 4585: RTCP-FB (AVPF / Feedback)

RTP is used by SIP, H.323 and even XMPP to send the actual media over the network. Once done, all the control over the media itself – negotiation of different bitrates, request for I-frames and the likes are usually done over the signaling protocols: H.245 when it comes to H.323, INFO and SDP when it comes to SIP. While this means that mapping protocols and gatewaying between them is a hassle, there’s an even bigger implication: We want media to go point-to-point as much as possible to reduce latency and increase quality, which means we would like all control mechanisms of the media to traverse the same route – and signaling is often split from the media and takes a different route through a different set of entities over the network.

To solve these issues, RTCP-FB was defined in RFC 4585, which is also known as RTP/AVPF. This defines a way for applications to send commands over RTCP from the receiver of the media to the sender.

Most of this standard deals with how sending such messages occur within RTCP in a way that won’t break the percentage RTCP takes out of the allotted bitrate for the media – a rather complex and daunting task.

But then its main use has come out in another RFC that “sits” right on top of it: RTC 5104. While this one has a bunch of control messages that can now be sent, the most useful one out of it is known as “FIR” – Full Intra Request, which is the similar to the Video Fast Update message sent in H.323.

With RFC 4585, RTCP becomes a protocol that can be used for some intelligent communication and not just pumping media over an IP network.

Oh, and it just so happens that the IMTC’s SIP Parity AG have placed the use of this RFC as an essential part of their evolving SIP Video Profile.

-

So you see, RTCP is a lot more than just an aside to RTP – it is a fully fledged protocol that is bound to be used and adopted as video calling becomes commonplace.

Make sure you take it into consideration the next time you develop a VoIP product.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

I’d like to revisit this a bit, due to some changes in the market, and explain how I see things moving forward.

Out of the many voice codecs available to us today, here are the ones that are the most interesting:

• G.722, a voice codec standardized by the ITU-T, providing an analog sound up to 7 kHz. It is a commonly used wideband codec for VoIP protocols such as H.323 and SIP.
• AAC-LD is a low delay audio codec that is defined in MPEG-4. It has the largest analog sound spectrum from all the codecs mentioned here. It is used by some of the video conferencing companies, but not all of them – some have opted not to use AAC at all while others have decided to go for AAC-LC (low complexity) instead. This makes the selection of an AAC-xx codec an issue if interoperability is what you have in mind.
• SILK is the codec used by Skype. It was unveiled by Skype a few years ago, with a promise to make it royalty free and widely available – most probably to make gatewaying from Skype to standards-based VoIP solutions easier. Fast forward to today, SILK is still mostly used by Skype.
• iSAC is GIPS own proprietary voice codec. After Google acquired GIPS and have open sourced it along with other GIPS technologies, it is freely available to others to use. While it hasn’t made significant inroads with VoIP systems, it is used by some of the messaging applications out there. Only time will tell if this will become prevalent in VoIP systems as well.
• AMR-WB, also known as G.722.2 is the voice codec of choice for wideband over cellular networks – that is, if you are developing something that has been specified and standardized for service providers – VoLTE or 3G-324M. What makes it interesting is that most mobile chipsets probably have its implementation etched into their hardware and not run as software on top – the tricky part is gaining access to it from 3^rd party applications.

To make it simple, here’s a table of these codecs:

Which one should you be using? That would depend on your setting and scenario. My priorities would be to start at G.722 for interoperability and move from there to the other options.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise