Real Time Communications Featured Article

Does WebRTC Need Fixing? Well...

March 30, 2016

As an evolving and not "fixed" standard, a lot of people are trying to make/expect/ask/demand WebRTC do things above and beyond its baseline capabilities.  The developer buzz is that WebRTC "can't" do certain things or needs to be "fixed" to do certain things.  I fall into the camp of "It is what it is" at this point, with evolution and user demand to drive capabilities, rather than overstretching WebRTC into doing things it is not designed and built to do.

Before going further, let me say that standards ARE important.  While some have expressed a belief that "Standards don't matter," it's important to note that standards make life easier for everyone from developers to end users.  More importantly, a single standard is best -- none of this multiple SIP standards/variations mess that hindered the evolution of seamless interoperability for VoIP over the years.  You plug in the "standard" into your problem/solution, it works, move on. 

WebRTC needs to evolve to a single standard everyone uses.  Right now, there's some forking between WebRTC 1.0 and ORTC which should resolve down the road into WebRTC NV being the one Ring, er, true standard that everyone can get behind.

Hopefully evolution will move WebRTC to a point where all browsers (cough-cough, Safari, cough-cough) don't need plug-ins for voice and video. Apple is working to bring WebRTC into the fold, but given their track record of late, they might wait until WebRTC NV is a formalized standard and who knows when that will happen.  Apple will ultimately get WebRTC into everything, so it is a matter of time and patience -- but most developer's can't wait, so we get a lot of programming duct tape to make WebRTC apps work with iOS and the Safari browser at this point in time.

Screensharing seems to be a pain point for current WebRTC applications.  WebRTC 1.0 wasn't designed for native screen sharing or the ability to enable native desktop control.  Instead, there's a bit more programming duct tape (plug-in) to enable screen sharing in Chrome and Firefox as a stock one-way video screen, with the ability to install the plug-in as needed on the fly -- this is the way all plug-ins should work, in my opinion.

Remote control of the desktop is something WebRTC isn't built for.  It's a security nightmare by any stretch of the imagination, so you need a different set of tools/code to implement it in order to do so in a relatively safe and reasonable fashion.

The one improvement I'd put on the to-do list for WebRTC is the ability to dynamically add in new audio and video codecs on the fly.  Everyone seems to be obsessed with having the one true set of fixed standards while continuing to play for new and better video codecs to be added down the road.  Why lock into something that you know will need to be replaced at some point in time?

WebRTC should have a baseline of "standard" codecs for interoperability. But there's no reason why a browser couldn't do a "go fetch" for a new codec either on a transactional one-time basis or to permanently save a new codec as a part of a maintenance update or other mechanism. Yes, it smacks of plug-ins and all the evil associated with them, but there should be some recognition that codecs should an interchangeable mechanism for communication rather than a set-in-stone feature set.

Edited by Stefania Viscusi

Article comments powered by Disqus

  Subscribe here for RTCW eNews