Four Reasons to Have Native WebRTC Support in Your Endpoints

On Monday this week I attended the second WebRTC meetup in Israel. The topic was NAT Traversal and there were two interesting presentations touching both the general issues and technologies related to it and WebRTC-specific topics. In the discussion following the presentations we had the opportunity to speak about codecs in WebRTC and Tsahi Levent-Levi (meetup organizer) presented his presentation from the Upperside 2012 WebRTC conference.

Leaving the VP8 vs. H.264 war aside, I want to touch the importance of supporting the WebRTC audio (Opus) and video (whatever that will be) codecs in the endpoint. There are four main reasons why I think it is worth the effort to go the extra mile and do this.

1) The Cloud and Multi-Purpose Data Centers

It was always better to have a call that doesn't require any transcoding and allows for media to go directly between the endpoints or if not possible only relayed transparently. WebRTC and cloud didn't invent this; they just made it a necessity.

Enterprises are moving to the cloud. This is correct for both UC and contact centers. Vendors are following this trend and making their solutions available on the cloud or provide it as a platform for service providers to host. The solutions are moving away from dedicated hardware (those boxes with many DSPs in them) to pure software products so they can run on multi-purpose data centers without requiring the data center to host a specific box of the vendor.

If your solution architecture requires computing-intensive tasks such as transcoding and decrypting/encrypting of the media, running it in a software-only architecture will be a harder task and surely less scalable.

2) Quality

If your architecture requires making a call say from a browser with Opus to an IP phone on your enterprise PBX running G.729 (as an example), somewhere on the way the audio will need to be transcoded. Transcoding means decoding the media and encoding it back in a different codec format. This task requires horsepower from the servers, especially when an HD audio codec is involved.

The higher the delay is, the lower the quality. Since this transcoding task takes time to compute, thus adding delay, it hurts the quality of the call.

The other alternative is to make the call using G.711, the lowest common denominator. It will remove the need for transcoding, but don't be looking for high call quality if this is the codec of choice.

Opus has built-in services for network resiliency and low delay; transcoding it to a different codec will eliminate benefiting from these features end-to-end.

The same logic applies to video if VP8 to H.264 transcoding is required.

3) Privacy

Since media in WebRTC is mandatorily encrypted, if you end up with a need to perform media transcoding, decrypting the media is a natural side effect. Media must be decrypted in order to be able to decode it. This in turn means you have a transcoding server in the middle that acts as man in the middle eliminating the end-to-end privacy.

The form in which media continues to flow from the transcoding server to the destination may add some impact on quality. If media, after being transcoded, will be encrypted again this will yield additional delay and further reduce quality. If it will not be encrypted again there will be no privacy between that server and the destination endpoint.

It is important to note that similar to the transcoding tasks detailed above, decrypting and encrypting the media is also a computing-intensive task that will increase the cost of deploying the service.

4) Scalability and Cost

The processing power required to support a given number of sessions if only signaling needs to be handled and media can be passed through transparently, versus a scenario in which media needs to be decrypted and transcoded, is an order of magnitude different. The need to perform these tasks increase the complexity of the solution, limits its ability to scale, and typically comes with a high price tag for the additional processing power consumed.

In Conclusion

The more I delve into this I can't find a single reason why not to include the WebRTC codecs in the endpoints. It is engineering time, it is not a simple task in some cases due to some hardware limitations on the endpoints, but the benefits yielded from having these codecs implemented end-to-end are far greater. This includes both business perspective (cost, simplicity) and user experience perspective (quality, privacy).

Amir Zmora is VP Products and Marketing for Radvision's Technology Business Unit.

*Opinions presented in this blog post represent the author's personal views and not necessarily those of his employer.