Does WebRTC Video Conferencing Services Pose a Threat to WebRTC PaaS Vendors?

I noticed something recently – there are vendors who end up integrating a video conferencing service instead of using WebRTC PaaS.

There are cases, where my first inclination would be to build on my own or pick up a WebRTC PaaS vendor. But then when I speak with the vendor, I find out he used a video conferencing service that he integrated instead.

Is this behavior an outlier? A trend? Something that WebRTC PaaS vendors should be worried about? Should they ignore it? Mere coincidence?

Here are a few examples.

Veeting and Mailbird

Veeting Rooms offers a video conferencing service in the cloud based on WebRTC. Their main point is privacy and security. Here are interviews I did with both Veeting and Mailbird.

Mailbird is an email client that needed a video conferencing service. So they integrated with Veeting. Why? Because it was there and available.

From talking to Veeting, I know that Mailbird isn’t the only such vendor.

Gruveo and SimplyBook.me

Gruveo is a video calling service for consumers. Their focus is on being the easiest one to use.

SimplyBook.me is an online booking system. They had customers asking for video calling capabilities for booked sessions, so they picked up Gruveo to fill that role.

From the link above, it seems like Gruveo is keen on additional integrations of this sort.

appear.in and Lucid Meetings

appear.in is another cloud video conferencing service. It targets consumers. Mostly. And is operated by a telecom company – Telenor. If you want to learn more, there’s an interview with appear.in on this site.

appear.in has its own set of integration APIs with a few vendors who used it. Such is the case with Lucid Meetings, who in a way is similar to SimplyBook.me. The reasons Lucid Meetings picked appear.in:

1. Free,
2. Had a documented way to integrate with them, and
3. Didn’t require any special login or an email address from a giant internet company (ahem),

vLine and their developer API

vLine had a developer API. Many have viewed them as a WebRTC PaaS. What they had was geared towards integration and not towards building a service on top. But that was hard to explain to people.

vLine have been quiet for the last two years, with the only post on their blog from 2014 is about closing their developer platform. Does that mean no more integration APIs? Just integration APIs? Focus on delivering a video calling service? Who knows.

Why aren’t these the same as WebRTC PaaS?

The service being integrated in the examples above is just that – an integration. Less of a development where data is shared, screens are defined, designed and implemented.

The control the vendor has over the service he integrates with is low to non-existent. As an example, appear.in doesn’t allow (yet) to whitelabel its service.

The focus of these services isn’t the same as that of the vendors integrating with them, and the business model between the two vendors will usually be an ad-hoc one.

Why is this important?

Until now, the tension has been between core development to outsourcing to a WebRTC PaaS. Oftentimes, I had to go with vendors through a process of understanding where their core competencies are. For most, voice and video communication start as core competency. WebRTC changes the equation towards making that part a commodity of sorts – something you can outsource and consume.

But now, there are vendors who see the real time communications part as something that can be integrated with minimal control and ownership. This shows how far we’ve gone since the early days of VoIP.

While there is no immediate threat to WebRTC PaaS vendors, this can be a growing trend in specific niches. If that happens, then we will see some of the WebRTC PaaS vendors trying to offer higher level components and services to their customers – the exact opposite trend to the unbundling one we have today.