Will Mobile Help or Hinder WebRTC?
I've been noticing a trend lately: Vendors opting for WebRTC instead of other options specifically because of mobile and not in spite of mobile.
If there's something that always concerned me about WebRTC, it is mobile. Or more accurately, the lack of any solid support for WebRTC in mobile.
But lately, from my discussions with many vendors, it seems like a lot of them are starting with WebRTC or migrating to WebRTC because of mobile. Why is that? There's no other alternative out there that even comes close.
What are your VoIP communication options on mobile?
There's this technology called Flash - not sure if you remember it. People say it worked great on desktop browsers, and it had around 99% install base across all browsers as a plugin. The real-time video quality it produces isn't the best. The echo cancellation is nothing much to write home about. And that Steve Jobs guy buried it forever when he decided never to have a place for it on iOS.
The rest is history.
Flash can easily be added to websites if you are doing a desktop scenario. But if mobile is what you want, then you are in for a lot of pain.
For iOS, even rudimentary things in Flash are hard to achieve. So taking this to the extreme of bidirectional video is a bit too much.
For Android, a Flash player requires manual configuration and handling of your phone - not something you can ask your users to do.
Go develop it on your own. There were companies doing video communications before WebRTC – it isn't rocket science.
The problem is cost. DIY is prohibitively expensive. So why go there at all?
3. Proprietary SDK
There are those who decide to use an SDK from a third party. Not one that supports WebRTC, but rather something that works in a proprietary fashion. Things like Vidyo and VSee come to mind here.
The challenge here is putting all the eggs in a single basket, as well as pricing. These proprietary solutions tend to be older than WebRTC, and they will usually have business models that aren't as accommodating as those based on an open source technology like WebRTC. Put simply, they are built by VoIP developers for VoIP developers.
WebRTC offers a compelling option. It has no real mobile support yet, but it has several things going for it:
1. Commercial grade, open source code – something you can take and port on your own. There are an increasing number of vendors who ported this on their own and can show their results. This adds credibility and reduces risk for those taking this route
2. A huge ecosystem base of over 500 vendors. This indicates that WebRTC isn't going to fade away and die quietly any time soon
3. There's a kind of certainty that mobile will be available for WebRTC (it is getting better every day that passes in the last two years already). So betting on it means mobile will be available at some point
If I were to start a service today that required video calling on mobile devices, my first choice would be WebRTC as a technology. From there, I'd have to decide if I want to go for a SaaS offering to reduce development effort or to go the DIY route.
Still not convinced? Gruveo was a guest contributor on my blog in the beginning of the year on the merits of Flash over WebRTC. They just switched to WebRTC in their latest release. One of the reasons behind their migration was mobile – Flash's inability to provide a solid solution for mobile.
Gruveo already runs on Android (through Chrome browser) and has an iOS app in the works as well.
With Google's own promise to have WebRTC in a webview soon enough, adding an Android app that is based on an HTML5 webview will probably be next in their roadmap.
Sometimes, it isn't the fact that the technology has a good answer for a given problem, but rather the fact that no other technology has a better answer.
WebRTC on mobile? Happening already.