Last week I attended ClueCon, which is a show focused on the FreeSwitch and open source telephony communities. I was happy to see WebRTC was a major topic, but surprised to find there was a lot of hesitancy around actually using WebRTC in production. I decided to focus my talk on exploring some of the reasons I often hear for not using WebRTC.

Here they are, in no particular order:

Excuse: “With ORTC replacing WebRTC, I don’t want to waste time on a old standard.”

Reality: Not true

There is no excuse here: ORTC is not at odds with WebRTC. Many of ORTC’s objects are already part of the WebRTC 1.0 specification. Moving forward to WebRTC NV (the Next Version after 1.0), WebRTC will continue to evolve to incorporate ORTC’s objects while maintaining backward compatibility.

Excuse: “Codecs will not interoperate with existing systems.”

Reality:  Not true

On the audio side, the browsers all support the modern Opus codec and the traditional G.711 telecom codec. There were never any major issues there.

On the video side, there was a debate between VP8 and H.264, but that has been resolved by mandating browser vendors implement both video codecs. Firefox has long supported H.264. With the latest version (52), Chrome now does too. Microsoft even has H.264AVC support behind a flag in its Edge browser.

Excuse: “Microsoft does not support WebRTC.”

Reality: Mostly not true

Microsoft supported ORTC in its initial Edge browser release, but is now adding WebRTC 1.0 support. However, there will be support on their Internet Explorer browser, and this is where most of the Microsoft browser users are today. As a result, we will need to wait for Windows 10 to fully replace older Windows version before Microsoft can more forcibly migrated its users to the newer Edge browser that includes WebRTC.

It is important to note, that in addition to the browser, Microsoft is also adding WebRTC support for Skype and even has WebRTC 1.0 support for native Windows applications.

Excuse: “Apple does not support WebRTC.”

Reality: True

Unfortunately this is true. Apple back an open source project called WebKit to enable its Safari web browser. They also require the use of WebKit inside 3rd party browsers, like Chrome and Firefox. WebKit does not support WebRTC. Because of Apple’s must-use-WebKit policy, this means no WebRTC inside Safari or any mobile web browser. WebRTC is now in active development on WebKit, but unfortunately we will need to wait until this is finished and made available inside Safari and iOS for broader use of WebRTC with Apple. In the interim this means using Chrome, Firefox, or Opera on your Mac and downloading native WebRTC apps (that don’t use the WebKit-based WebView) from the App Store for iOS.

Excuse: “I can keep using Flash.”

Reality: False

Flash RTMP was the major option for running RTC on the web prior to WebRTC. However, usage of the proprietary platform has atrophied as performance and security issues have increased. With the growth of HTML5, it is systematically being removed from the browser. Chrome and Firefox already make you provide extra confirmations to run flash on most sites. In September Chrome will block flash that loads in the background. Firefox isn’t far behind. If you ignore VoIP quality complaints,  is getting harder and harder to run a Flash VoIP app at all and it will only get worse.

Excuse: “WebRTC standards are still in flux.”

Reality: Partly true

The Media Capture and Streams specification that gives a browser or app access to the camera and microphone is effectively done. The WebRTC 1.0 specification that governs everything else in WebRTC is not. However, one should ask if this even matters considering Google alone has reported 2 billion WebRTC browsers deployed and reports more than 1 billion WebRTC minutes a week. The browsers vendors have already implemented the most widely used functions. 
Will the browser vendors change their implementations to match updated standards? Yes. Does this mean you will need to completely rewrite your application? No and there are tools like adapter.js than can limit rewrites and browser differences.

Excuse: “WebRTC is buggy .”

Reality: Partly true

Philipp Hancke, my webrtcHacks co-author, and WebRTC engineer gave a great talk on identifying WebRTC bugs and taking measurements. He mentioned issues like browser implementation problems and forced browser updated breaking things (see my post on this topic here).

It is true, like all complex technology there are bugs and WebRTC is no exception. However, unlike many technologies, WebRTC offers a bunch of advantages to developers to make your life easier, notably:

  • Billions of users – Facebook with its Messenger platform, Google itself with Hangouts and Duo, and many, many of other aggressive users are likely to catch widespread issues early.
  • A participatory community with regular forum participants and people like Philipp who routinely share data and best practices
  • Projects like adapter.js mostly allow developers to write to the spec while inter-operating with the major browsers.

WebRTC certainly has some issues, but for a technology that is only 5 years old, it is maturing very rapidly. I can’t think of any other RTC-related technology that has anywhere near the rapid adoption or improvement curve of WebRTC.


If you want an excuse for not doing WebRTC, you can always look hard enough and find one.  For the vast majority of use cases out there, there just aren’t that many reasons left.