WebRTC Facts and Lies

Nowadays there is some hype around the WebRTC initiative leading to some missunderstandings.   I have collected some frequently asked questions to help to understand what is and what is not WebRTC to avoid it becaming the next big buzzword in the telco industry.

What is WebRTC?

Is an initiative to add capabilities to send/receive audio and video in the browsers without requiring additional plugins. It is exactly the same that happened with video playing and today most modern browsers have native support for that capability.

Who is behind WebRTC?

Google is the initial and main supporter but Opera and Firefox have been also supporting it from the very beginning.  Lots of individual contributors from different companies (f.e. Cisco or Ericsson) are working on this in standardization forums. Efforts to achieve WebRTC goals threefold now: Google with individual contributors building a reference implementation, W3C defining the APIs to be exposed in the web browsers to developers and IETF defining the protocols being used by the browsers to offer those capabilities.

Is WebRTC a new technology?

No, 99% of the technology behind WebRTC was already in place and used by commercial applications like Skype, Tango or TU Me. WebRTC is basically a tag but not bringing any new technology as it is based in codecs, protocols and NAT traversal and encryption solutions that have been used in other applications out of the web browsers for years.

Is this something new?

No, the community has been working for two years on this.  First Ericsson implementation was shown in May/2011 and W3C group was officially created in May/2011.

Can I use it out of browsers?

WebRTC is an initiative just focused on browsers because there isn’t any problem to solve in other environments like native mobile applications.  But the libraries that are being created by the community as reference implementation to be integrated in browsers are very high quality solutions that can be integrated in any other RTC application with enough knowledge and resources.

How many implementations are there?

There is basically a single implementation for the core (media engine for audio and video processing) that is being integrated by each browser vendor.  Each vendor has freedom to reimplement some parts and they are customizing the network layer and the PeerConnection implementation.

Is this SIP or XMPP?

None of them since WebRTC is agnostic to control protocol.  Each application have to solve how to invite and accept/reject the calls for example using any “cloud” messaging solution like PubNub.com to send those control messages between users.   WebRTC only solves the audio and video transmission after that negotiation has been carried out.

If I decide to use SIP do I need to use SIP over WebSockets?

No, you can use any standard or proprietary transport for SIP messages (even email if you want :-)).   But the only standard SIP solution compatible with browsers is SIP over WebSockets.

Is it interoperable with other VoIP solutions?

Probably not mostly because of the encryption of media flows and the codecs supported.   That interoperability can be always provided introducing a gateway in the middle to provide any translation needed at protocols or codecs level.

What encryption is provided by WebRTC implementations?

IETF decided to mandate DTLS-SRTP, so all the traffic is encrypted and the keys negotiation is performed in the media flow with some fingerprints exchanged at the control protocol level.

What codecs are provided by WebRTC implementations?

For audio there is strong consensus on mandating support for G711 and Opus (very high quality and modern codec just standardize after some years of effort).  For video the discussion is ongoing and there are two options on the table: no agreement on a mandatory codec or mandating VP8.  I’m not optimistic on reaching a conclusion on the video codec and I think market will dictate the the-facto standard in the mid term.

What NAT traversal solutions are provided by WebRTC implementations?

WebRTC includes all the standard NAT traversal mechanisms defined in IETF and also being used for years in commercial services like GTalk.  ICE to figure out the best path between two endpoints, STUN to find the public address of endpoints and TURN to create tunnels to relay traffic as a last resort solution.  The combination of them is supposed to give the optimal solution for all the NAT cases.

Voice/video quality will be bad as this is free, right?

Voice/video quality will be close to the best possible as most of the browser vendors are integrating the reference implementation based on the components acquired by Google (~200M$) from the most prominent VoIP company called GIPS and from the video codec provider On2. This solution is including best in class technology for all the algorithms that have a strong impact on the user experience: AEC, NS, AGC, Jitter Buffer

Ok, but without QoS mechanisms in the network this is not going to work

Did you hear about Skype?

Does it require some server infrastructure?

You need a server infrastructure for the control protocol, but that part is not standardized and each service provider can implement its own solution for the sake of flexibility.

Do I need the WebRTC box that IMS vendors are trying to sell me?

In the unfortunate case you have to use an IMS infrastructure provided by a traditional vendor you will probably have an access box (SBC) that is probably missing some features needed (mostly the websockets, ICE and SRTP support).  Providers should end up including support for those features in the SBC but in the meantime you can add an additional box in front of it.
If you are using an opensource plain SIP solution (f.e. kamailio) you won’t probably need any additional support.

Does it support PSTN interconnection?

PSTN interconnection is provided by gateways.  To have PSTN interconnection you will need a gateway (or another box in front of it) understanding ICE, SRTP and OPUS. You can fallback to G.711 for the encoding if the bandwidth is not a problem.

What is a PeerConnection?

PeerConnection is the basic API exponsing WebRTC capabilities by the browsers to web developers. It basically exposes the capabilities to start and stop different media channels between two peers.

Do developers need something else?

Most developers would appreciate higher level APIs abstracting a specific call control solution and also hiding all the PeerConnection handling complexities.  There are already javascript libraries provided by players like OpenTok or Phono that are offering this level of abstraction.

Can I send arbitrary data using PeerConnection?

There is ongoing work to be able to establish direct data channels between browsers in the same way that we establish the audio and video channels.

When will it be available for production?

You can use it today in Chrome browsers by activating it in the preferences.  It is expected that half of the browsers market (Chrome, Firefox, Opera) will support this without requiring any manual enabling on the beginning of 2013.

What can I do if there are incompatibilities/missing features between browsers?

This is a probable scenario specially because of the video codec.  The solutions as usual can be some server-side gateway to translate protocols/codecs or the use of plugins for the browsers “miss-behaving” (for example the already existing Google Chrome Frame plugin)

What are the Microsoft and Apple plans?

I don’t care know.

What is Google purpose with WebRTC?

Dominate the world.


Thank you for the review and contributions to this list from Oscar and Christian.

Comments

Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Image
Bandwidth estimation is probably the most critical component in the video engine of WebRTC. The bandwidth estimation (BWE) module is responsible for deciding how much video* traffic you can send without congesting the network to prevent degradation of the video quality. In the past bandwidth estimation algorithms used to be very rudimentary and based mostly on packet loss. Basically we used to start increasing slowly the video bitrate until we detected packets being lost.  To detect the packet loss you use the standard RTCP feedback mechanisms where the receiver side reports packet loss periodically using RTCP Receiver Report (RR) messages. Modern bandwidth estimation algorithms are more advanced and try to detect congestion before it is bad enough to make routers discard packets. These algorithms predicts congestion analyzing the delay between packets. The idea is that when you start having some congestion, the buffers in the routers will start filling and the delay wil...
Read more

Improving Real Time Communications with Machine Learning

Image
When we talk about the applications of Artificial Intelligence / Machine Learning (AI/ML) for Real Time Communications (RTC) we can group them in two different planes: Service Level : There are many features that can be added to a videoconference service, for example identification of the participants, augmented reality, emotion detection, speech transcription or audio translation .  These features are usually based on image and speech recognition and language processing. Infrastructure Level : There are many ways to apply ML that do not provide new features but improve the quality and/or reliability of the audio/video transmission. Service level applications are fun, but they are more for Product Managers and I like technology more, so in the next sections I will try to describe possible applications of AI/ML for Real Time Communications at Infrastructure Level organizing those ideas in five different categories. Optimizing video quality Some of the ML algorithms use...
Read more

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Image
There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams. There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP. 1. U se the standard  b=AS:BITRATE (Chrome) or b=TIAS:BITRATE  (Firefox) attributes in the SDP for the audio or video channel[1] 2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2] 3. Use the proprietary x-max-bitrate attribute in the video channel of the...
Read more