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

11/05/2015

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

Trojan horse

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.

 

Planning on selecting a CPaaS vendor? Check out this shortlist of CPaaS vendor selection metrics:

Responses

Art Matsak says:
May 11, 2015

Whether you build on your own or use a WebRTC PaaS, there are development and maintenance costs involved, and not vendors are prepared to pay those. Here are some of the common reasons we hear from our integration partners:

– Basic integration is free
– All the necessary functionality is oftentimes already there
– The ever increasing brand recognition for Gruveo means a familiar widget and less of a barrier for users to click that “Video call” button
– Since Gruveo is running a public service, it’s in our best interest to keep the solution secure and working – something a vendor gets to enjoy at no cost.

Reply
John Keith says:
May 12, 2015

Hi Tsahi,

We’ve built deep integrations (Turbobridge for SIP / telecom — webrtc coming!), Twilio (webrtc with flash fallback) for core audio options, and Glance for integrated screen sharing. At some level even a meeting management platform like ours needs a core set of capabilities and a business-level arrangement with our partners.

But — we have increasingly found pressure for a variety of other options already in use out there. For us to build and maintain deeply embedded integrations for all these options would kill us 🙂 I think there’s a lot of interest in bringing personal, consumer-oriented tech into the business setting. That leads us to look for easy wins, such as our appear.in integration.

We will, for example, launch a group Skype call if that’s what you already use and prefer. Same for a Google Hangout (soon) or appear.in, which is drop-dead simple for people to join and use. And there are probably more of these “arms-length integrations” as well.

Because our value focus is on meeting management, we want to be as accommodating as possible for people’s preferred communication technology. The easy integration wins are great for that.

Reply
    Tsahi Levent-Levi says:
    May 12, 2015

    John, thanks for taking the time to explain where you’re headed.

    For a scheduling system, this seems like the right approach – you’d prefer being agnostic and support whatever your customers are comfortable with.

    Reply

Comment