First-hand: pitfalls on the way to support WebRTC

Many of you have heard about the new standard for the implementation of realtime web communications, aka WebRTC. We are developing services for voice communication (click-to-call / tap-to-call) with users of websites and mobile applications. And that is why we are very close to the idea of ​​voice and video calls directly from the browser without installing additional plug-ins. In general, any additional software. Our company is part of the W3C working group on the development of this standard along with Google, Mozilla, Cisco, Ericsson, Skype and many others (yes, we are in a great company). A team of serious professionals, such as Cullen Jennings (Cisco), Justin Uberti (Google), Daniel Burnett (Voxeo), Cary FitzGerald, is working on the standard. Many of them participated in the creation of IP-telephony in the form that we know it for the past 10-15 years.

The initiator of the entire WebRTC movement was Google after the acquisition of GIPS. They were the first to add support for the latest draft version of the standard to their browser. WebRTC already works fine in Google Chrome 23. But yes, in order for the WebRTC version of your online service to take off, you need to spend time and figure out how it all works now. And in order for your WebRTC service to continue to work, you also need to monitor what is happening in the working group and all changes to the standard, which is not as trivial as it seems.

A bit of history. The first browser in which at least some support for WebRTC was implemented was an experimental browser from Ericsson. We could not wait to try WebRTC in action, and we “filed” support in such a way that our servers would work with this browser. As it turned out later, it was a rather silly idea. As soon as Google took over the business, all Ericsson's developments were sent far away, and the constant change of the standard began, as well as the corresponding implementation in the Chrome Canary developer assembly.
')
There were quite funny moments when browser developers used some strange RFC variants (or didn’t use them at all) and it turned out that STUN or ICE had to be rewritten again to make it work at least somehow. As a result, common sense won, and they did everything according to the RFC, but a lot of time was spent on dancing with a tambourine and explaining that doing so is not good.

There are several points that now cause difficulties when working with WebRTC:

1. Work on the standard is in full swing, and some kind of finished version is still far away. Everything is changing - for example, there are new versions of browsers that require re-checking and often reworking the entire implementation. It is not a fact that there is backward compatibility. Often there is none.
2. The implementation of standard protocols (for example, SDP) is still far from ideal. Say, now PeerConnection is able to send video and audio through only one port, even if the other participant specifies the opposite in SDP. True in fairness it should be noted that the situation is gradually being corrected. For example, ICE in recent versions of Chrome works in accordance with the RFC.
3. The impossibility of implementing Media Control XML methods adds complexity to integration with SIP. Therefore, with the loss of packets from the gateway to the SIP equipment, there will be problems with recovering the picture. Colleagues from Google said that they implemented this at the RTP protocol level, so this issue still needs to be dealt with.
4. There is no support for common video codecs (read H.264). Of course, some softphones already have a VP8 implementation, but no industrial solution yet supports this codec. There is no clarity with this question yet, there are a number of companies advocating for H.264 support, but since the codec is patented by MPEG-LA, and only royalty free codecs are planned to be used, only VP8 is currently available.

From the point of view of UX / UI, WebRTC is clearly better than Flash (see screenshot), but there are a number of flaws that we hope will be fixed in the future. For example, if you save the recorder selection (only available when using HTTPS), then to reset this setting you need to go to Settings -> Advanced Settings ... -> Privacy -> Content Settings ... -> Media -> Manage exceptions ... Do you need to say that a regular user will never get there?

It was (Flash)


It became (WebRTC)


I must say that the sound quality when using WebRTC is really seriously better than in Flash. For example, WebRTC has full automatic gain control (AGC, Automatic Gain Control) for a microphone, and Adobe, for some apparently religious reasons, did not turn on such a useful function. Well, the rest of the GIPS audio engine works very well. In the near future, WebRTC will be able to use the Opus audio codec, which is a hybrid of Skype SILK and CELT and has already been adopted as mandatory for WebRTC along with G.711. Google is already hard at work on supporting WebRTC for the mobile version of Chrome for Android, which means that there is a serious future on mobile platforms (Adobe abandoned attempts to promote and develop Flash for mobile).

And finally: WebRTC Conf & Expo announced that WebRTC support will be added in the release version of Firefox 18, and this remarkable event will occur approximately in April 2013. We are waiting for Opera, IE and Safari. By the way, we were direct participants of the conference and even managed to win a prize, we will try to write a separate post about it.