It takes 2 for dancing the WebRTC tango
Browser support for WebRTC and interoperability between browsers supporting WebRTC is considered by many a showstopper for WebRTC adoption.
While all these issues can be mitigated, it is not always an easy issue to solve and in some cases, hinders user experience.
The lack of support for WebRTC in browsers such as Safari, Mac and iOS is in the hands of the vendor, Apple in this case. Similarly, it is an issue only Microsoft can solve when it comes to Internet Explorer (and it doesn’t look as if they will, they are settling with WebRTC in Edge).
There are ways around this issue using a plugin on Mac or PC which means download is required, or a native application/SDK with WebRTC compiled into it in the case of iOS.
The other part related to WebRTC supporting browsers interoperability is a matter of adhering to the standards.
While there is adapter.js that quests to bridge browser compatibility issues, it focuses mainly on API mapping. There are other issues, such as differences in SDP, not handled by adapter.js. Such issue cause applications to break when used on dissimilar browsers. The constant changes in browser versions and in some cases, lack of backward compatibility between them, make this a moving target.
Now that we are close to really finalizing the WebRTC standards in IETF and W3C, Google came out with an encouraging announcement. Google is targeting to finalize the standards and most importantly, make WebRTC in Chrome standards compliant.
Positive and long waited for news.
Google plans to push for completion of WebRTC 1.0 this year in 4 main areas:
Finalize the standards
That’s work to be done at IETF and W3C by the community (Google of course being part of it). In the previous live WebRTCStandards Webinar we touched some of the latest standards work and mentioned the fact that work on the major things is done, it is mainly the small details that are left to be closed.
Resolve WebRTC spec incompatibilities in Chrome
This one is a major point.
Although Google is part of the standards work, there are areas in which Chrome and the WebRTC open source by Google are not following the changes in the standards.
These include supporting RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver that are related to RTP Media API.
Being compliant with the getStats identifiers.
You are probably asking what’s the difference between these two representations of SDP.
Originally there were 2 IETF drafts. One called Unified Plan and another titled Plan B.
The main debate was around how to represent a large number of media sources/streams in the SDP.
Unified plan takes the approach of having an m= line per each media source.
In Plan B on the other hand an m= line is an “envelope” that includes multiple media sources per one defined transport.
Mapping between these 2 is not trivial and having common support for Unified Plan as the standards define will simplify interoperability between Chrome and Firefox.
Cross browser interoperability testing
To strengthen the interoperability between all browsers, a Web Platform Test suite is being developed with a goal to enable API and other functional tests.
Resolve reliability issues
Anyone using WebRTC for calls encounter once in a while audio capture issues or echo. The guys at Google are aware of these issues and are working on solving them. Based on the message from Google, they plan on significant infrastructure improvements for tackling these issues.
Why this is important
The browser compatibility has been an excuse for companies to delay WebRTC adoption and a pain for developers.
Getting these issues behind us is important for the maturity of WebRTC and for developers to get more hours of sleep :).