What do you do on an unsupported browser with your WebRTC service?
Tomorrow we start off in Santa Clara with WebRTC Conference & Expo. There are many events around the world now that do WebRTC. This is the second one just this month in Santa Clara, with other events this month and the next, either giving WebRTC a day or the whole show.
This week, I’ll be working as a moderator in many of the panels and sessions, and one of the things I’ll be asking is the question around fallback – it is something that I am asked a lot, so why not let other suffer the same fate?
WebRTC doesn’t work on all browsers, though situation is getting better. What are the options that vendors have when the time comes?
1. Ignore
Take the easy path of ignoring the unsupported browsers. This means your service won’t work on IE or Safari and you can always place a nasty/nice message telling the user to switch to a somewhat more “advanced” browser.
Might not work at all for some cases (think of restrictive IT people who must have their IE browser in all machines). And in others it might mean losing users.
But it is valid, and happens everywhere around us.
Just to make a point – my blog gets access by Chrome and Firefox together by 78% of my visitors. Ignoring the rest might not be such a bad idea for a service on my blog that requires WebRTC…
2. Leave
This is what I say to those who whine that they can’t use WebRTC because it doesn’t work on IE. Just leave. Shoo. Go somewhere else. Don’t use WebRTC if it doesn’t fit your need.
Go build your own solution from scratch and then complain again that it isn’t accessible from a browser.
You can never satisfy everyone.
3. Flash
WebRTC can’t be used? Just use Flash – good chances are it is already installed on the browser anyway.
Sure – quality will suffer and you’ll get a ton of headache getting this to work properly when some use Flash and others WebRTC in the same session – but if you really need it, then there’s a solution available for you.
4. Plugin
You can always wrap WebRTC as a plugin and go install it on the non-supporting browser when necessary.
Yap. Some might end up with technical issues installing it, others will just skip your service – but it gets you a bit more eyeballs.
–
What is your pick and why?
Need to know where WebRTC is available? Download this free WebRTC Device Cheat Sheet.
My vote is for 4 and 1 according to use case :). 2 is an impolite version of 1 and 3 will be much more complicated than 4 at the end of the day.
We have taken the plugin approach for a few reasons:
* Flash is not capable of reasonable RTC in many use cases. Mostly because it uses the proprietary RTMP which is a TCP protocol and so not for suitable RTC.
* Plugin can be ‘WebRTC’ in that it is a full WebRTC stack (although in our case the AddLive APIs are different because we focus on multiparty use cases).
* The plugin can ‘evergreen’ and self updates, which means only one install required.
The problem with the plugin is that:
* It is a barrier to entry. Sometimes this is difficult to overcome (say in a contact center type use case), and others it isn’t (deployed centrally by a company).
* Browsers are moving away from plugins. Both Chrome and Firefox have announced that they want to move away from NPAPI for security reasons. Fortunately these are the two WebRTC browsers.
See everyone at the WebRTC Expo tomorrow!
Flash supports UDP, it’s called RTMFP and it’s not bad I would say. But overall quality of audio/video engine in Flash isn’t good. WebRTC is much better.
We use option 3.
We use Flash fallback in our Flashphoner Web Call Server product.
In fact, Flash Player is the most popular browser plugin that’s why we use this fallback.
The main idea of browser RTC communications is “Do not install any additional software “. If we use Flash player it’s closer to this aim than if we use some other RTC plugin.
But i’m agree that such RTC plugin will provide better voice quality than Flash.
I hope Flash Player team will add WebRTC stack into the Flash Player. It would be a perfect progress!
We need to provide a fallback to flash, or polyfill if the browser does not support the WebRTC getUserMedia feature.
Option 1: flash fallback
We will replicate the flash implementation originally from the LeQue repository as the fallback, as an interim solution. This will allow us to send recorded audio, after clicking save, which will send the entire audio recording as a wav file to a specified directory within the server.
When we have successfully replicated the earlier implementation, we will learn how to program in ActionScript 3 using FDT with the Adobe Flex 4.6 SDK. We write our own ActionScript 3 with the microphone class, which will allow us to stream audio from the browser to server, unlike our previous implementation. When this new streaming implementation has been completely written, we will use it to replace the replicated flash implementation.
Option 2: getUserMedia polyfill
Implement Temasys WebRTC Plugin for getUserMedia. This will polyfill getUserMedia for the Safari, and Internet Explorer browsers. The plugin may require specific instructions to be followed.
Note: Other polyfill / plugin options are available in case the latter does not work.
I have no clue why would anyone even consider using Flash these days. It makes no sense at all. Plugins make sense maybe for IE, and even that is a stretch. In 2018 people have moved on. Those that haven’t are figuring out how to wrap everything into Electron and serve it as an app where needed.