WebRTC’s Extremes. Aggregation or Embedability? Federated or Siloed?

WebRTC is but a technology. Its adoption happens at the edges.

It is interesting to see what people do with WebRTC - what use cases do they tackle and what kind of solutions do they come up with. Here are a few opposite trends that are shaping up to be mainstream approaches to wielding WebRTC.

1. Aggregation

In many cases, WebRTC is used to aggregate. The most common example is expert marketplaces. Popexpert and 24sessions are good examples of such aggregators. You open up your own page on these services, state what services you offer and your asking price. People can search for you and schedule a video session with you. Interesting to see in this space LiveNinja who recently shutdown their aggregation service, shifting towards and embedability alternative.

2. Embedablity

The opposite of aggregating everyone into a single domain is to enable embedding the service onto the expert's own website. The company will offer a piece of JavaScript code or a widget that can be placed on any website, providing the necessary functionality.

Aggregation of Embedability?

Which one would be preferred, and to whom? The Vendor in our case, has more power as an aggregator. He is in charge of all the interaction, offering the gateway into his domain. Succeeding here, places him in a position of power, usually way above the people and companies he serves. The Expert may enjoy an aggregator when he is unknown. Having an easy way to manage his online presentation and being reachable is an advantage. For someone who is already known, or that have spent the time to make a brand of himself online, being aggregated on someone else's site may dilute his value or position him too close to his competitors - not something you'd want doing. The Customer on one hand, can easily find his way through an aggregator. But on the other hand, it places the expert or service he is reaching out to at a distance. One which may or may not be desired, depending on the specific industry and level of trust in it. Ben Thompson has a good read about aggregation theory which I warmly suggest reading.  

3. Silo

Most WebRTC services live in their own silo world. You envision a service, you build the use case with WebRTC, and that's it. If someone needs to connect through your service - he must use your service - he can't get connected from anywhere elsewhere. Unless you add gateways into the system, but that is done for specific needs and monetization. I've talked about WebRTC islands two years ago. Here's a presentation about it: http://www.slideshare.net/tsahil/webrtc-islands WebRTC makes it too easy to build your own island, so many end up doing so. Others are hung up to the idea of federations:

4. Federation

Why not allow me to use whatever service I want to call to you, and you use whatever service you prefer to receive that call? Think calling from Skype to WeChat. Or ooVoo to Hangouts. What a wonderful world that would be. Apparently, it doesn't happen because the business need of these vendors isn't there - they rather be their own silos. Who is federating then?

• Some connect to the PSTN in order to "federate" - or to enjoy the network effect of the legacy phone system
• Those who have a network already (federated or not), end up using WebRTC as an access point. That's what Polycom did recently with their RealPresence Web Suite.
• Solutions such as Matrix, looking to offer a framework that enables federated signaling that is suitable for WebRTC as well

Why is this important?

At the end of the day, WebRTC is a building block. A piece of technology. Different people and companies end up doing different things with it.