Démystifions le WebRTC ou la découverte de “Odigo Visual Support”

Demystifying Web-RTC or re-Discovering AudioVisual Communication in the Browser

Prelude: 2016’s been hectic and full of learning. So much, so i think, that i have decided to try the following “blogging approach”. It isn’t about finding topics to write about. It’s about writing, period. What if instead of waiting to have a fully written blog article one could share its core structure? Could readers contribute and writers of course come back to it at any time? Here’s how this experiment could look like [#draftBlogging]:

Once upon a time… WebRTC

Since when have we been talking about this?



(1) What’s Web-RTC?

– Wikipedia

In May 2011, Google released an open source project for browser-based real-time communication known as WebRTC. This has been followed by ongoing work to standardise the relevant protocols in the IETF and browser APIs in the W3C.

WebRTC (Web Real-Time Communication) supports browser-to-browser applications for voice calling, video chat, and P2P file sharing without the need of either internal or external plugins.

– WebRTC.org

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

[WebRTC.org’s] mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others. This page is maintained by the Google Chrome team.

– Personally

WebRTC, the term, has been widely used and abused. You may hear somewhat the following: “WebRTC allows video communication in across browsers and and mobile devices without the need of additional software/plugins”. Although this is somewhat true in a handful of limited scenarios: it is NOT and cannot be a “universal statement” [at least for now]. Companies that want to leverage webRTC for professional purposes face a number of challenges that i will cover today [hopefully] from a technico-functional [geeky driven] POV. I actually discover all of this the hard way, but this, is a story for another blog post.


(2) Where is it limited? or What challenges is it facing?

(2.a) WebRTC: browsers supported


In which cases can WebRTC by leveraged?
In which cases can WebRTC by leveraged?

Did you know? Apple has forbidden google to “embark” WebRTC into its iOS Chrome App: so there you have it. In iOS it won’t work if you don’t develop your own App [integrating WebRTC SDK].

(2.c) Business Case underlining limitation:

  • Customer side: using all browsers
    • As a company you must provide the same experience across browsers and devices. Currently NOT possible if ONLY leveraing WebRTC.
  • Company side: using mostly IE
    • Specially in the contact-center or call center world, what i’ve seen mostly is the use of IE: webRTC NOT compliant.
    • Although this is changing quickly specially among growing companies from SMBs to Enterprises.
    • If the “good old” titanics are still using IE, then you won’t be able to leverage WebRTC alone on the “agent” side of things, even if, the end-client may be able to contact via a fully compliant webRTC browser.
  • Signalisation layer vs. Media Layer
    • Huh? Yes, Signalisation. We’ll get there. Let’s first note that in “raw”, WebRTC is P2P.
    • By default the WebRTC protocol only provides the “media layer”: this sounds good enough. True, we need the media to fully achieve a audio & video [both media] communication. “Jusqu’ici tout va bien”.
    • But, what if, as a business, you want provision your users, know when Carlos (point A) calls Pablo (point B), and because of these info actually monitor these interactions in RT and at “posteriori”?
    • Well, if you are a company that needs this, you need to develop this capability yourself: this is the “signalisation layer”.
    • By default a “signalisation layer” is NOT part of the WebRTC protocol.
WebRTC: Media vs Signalisation Layers
WebRTC: Media vs Signalisation Layers

(3) How can these challenges be addressed?

  1. Code: Develop Signalisation layer on top of Web RTC
  2. Code more: Develop Plugin, Extension, SDK for Browsers & Mobile(s) that do Not Support Web RTC
  3. Deploy Infra: Develop Global Cloud: allows you to go beyond P2P and enable security to business standard levels.
How to offer universal & homogenous experiences across devices & browsers?
How to offer universal & homogenous experiences across devices & browsers?

(4) AudioVisual Communication within the browser: Why is it relevant for businesses?

Démystifions le WebRTC ou la découverte de “Odigo Visual Support”
Démystifions le WebRTC ou la découverte de “Odigo Visual Support”

This point (4) almost deserves its own blog post. Don’t you think? I do 😉

Stay tune for Screencasts underlining the following use cases and let’s wrap up.

  1. Insurance Use Case
  2. Bank Use Case
  3. Field Service Use Case
  4. Tele Medicine Use Case
  5. Retail/DIY Use Case

In a nutshell: …

7 Challenges brought forward by WebRTC alone?
7 Challenges brought forward by WebRTC alone?

Thank you.



Leave a Reply

Your email address will not be published. Required fields are marked *