On February 4th Mozilla and Google announced that their respective browsers could now talk to each other via WebRTC. This is another big milestone in WebRTC’s path towards becoming available in all modern web browsers, albeit, today only in an early development build of Firefox, version 21+ (currently Nightly and soon to be Aurora).
We’ve also been working hard on making OpenTok on WebRTC work with both Firefox and Chrome so you too can enjoy all this cross-browser goodness!
Off to the races
If you’re a Firefox user already you may want to set up a separate profile to test with. This will keep your default profile clean, and your test profile will likely also start up a bit faster than your default one. You can find instructions on how to do this here and here.
If you’re testing with Chrome, you will want to make sure that you have updated to the latest version (version 25 at the time of this article), which has all of the fixes required for interoperability with Firefox. All of the relevant WebRTC bits are enabled by default in Firefox 21+ and in Chrome 25, so you should be ready to roll. Now go have a play with TokBox’s OpenTok on WebRTC demo. Then come back here afterwards.
When can I have this in the production release of Firefox?
Parts of WebRTC are working in the current production release version of Firefox (Firefox 19). However, Firefox 21 is the version that interoperates successfully with Chrome, and it also has all of the WebRTC preferences turned on by default. The gang at Mozilla is also pushing hard to fix lots of critical WebRTC bugs before production release of Firefox 21 and hopefully turning on WebRTC for everyone. According to the Mozilla release calendar, Firefox 21 is targeted to be released the week of May 13th.
If this isn’t in the production release of Firefox, why is this news?
What we’re doing today is giving you a head start.
The great thing about OpenTok on WebRTC is that we make face-to-face video work in your users’ browsers when those browsers are ready to work correctly. So our announcement today lets you know that we are ready for Firefox WebRTC support to go production. Right now, you can install Firefox Aurora and use it to test your app using OpenTok on WebRTC. And you can watch as Firefox 21 makes it from Aurora to Beta and then to release and know when a big new chunk of your users can get access to WebRTC through OpenTok on WebRTC, all without your having to write an extra line of code.
What doesn’t work yet?
Mozilla isn’t quite done yet, so there are still some holes. The biggest one involves anything to do with disabling audio and video tracks. Namely:
- Muting audio
- subscribeToAudio and subscribeToVideo on Subscribers
- publishAudio and publishVideo on Publishers
You may also see some connectivity issues in particularly restrictive networks. We’re working on these issues now, and we’ll update you as we have good news to share in the not too distant future.
What were some of the challenges of getting Firefox and Chrome to play nicely?
Some of things we had to do were pretty straight-forward – normalizing the cosmetic differences between the APIs, for example. This just involved making sure that we were using the appropriate vendor prefixed object and function names, say webkitGetUserMedia in Chrome and mozGetUserMedia in Mozilla.
The more complex bits involved working around browser specific issues and incompatibilities in the messaging layer (this is the part that uses text blobs of SDP). One notable example was that earlier implementations in Chrome and Firefox didn’t support compatible implementations of cryptography, with Firefox supporting DTLS and Chrome SDES. This was eventually resolved, but a new related issue popped up in Chrome as a result.
Simply, DTLS adds an extra “a=fingerprint” line to the SDP payload which makes Chrome 25 incorrectly assume that the payload is SDES when it sees it. If SDES was being used there should also be an “a=crypto” line, but in this case there won’t be. So Chrome complains and won’t accept the SDP message.
As Chrome doesn’t actually care about the value of the crypto line, only that it’s present and well formed, the solution is to add a dummy crypto line when sending offers from Firefox to Chrome. Google is landing a fix for this in Chrome 26, but leaving the extra line in causes no harm and allows compatibility with Chrome 25. The dummy line we add in OpenTok looks like this:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:FakeFakeFakeFakeFakeFakeFakeFakeFakeFake\\r\\n
On the Mozilla side, Firefox doesn’t support FQDNs when specifying ICE servers for the PeerConnection. There’s a Bug open for this on Bugzilla, but in the meantime, ICE servers must to be specified as raw IPs for Firefox.
Another issue is caused by Firefox sending Data Channel information as part of its JSEP Offers – something that Firefox is doing temporarily until its Data Channels implementation is completed. Unfortunately this upsets Chrome and requires another workaround.
The good news is that we are doing all this hard work for you – making OpenTok on WebRTC interoperate smoothly – so you can spend your time building great applications, not worrying about browser compatibility between different implementations of the WebRTC standard.
Wrapping it up
At TokBox we’re super excited to see another great browser jump on board with the WebRTC standard, and we’re really impressed with how quickly the Firefox and Chrome teams have come together to make this happen. We really believe in the power of WebRTC – in particular, in the quality of the video and audio it delivers while maintaining low latency. We’re constantly keeping an eye out for all of the new developments in WebRTC, making sure we’re staying ahead of the curve to keep our API supporting the latest and greatest. Now we’re off to take a hard look at Microsoft’s first implementation of CU-RTC-Web.