 
## Table of Contents

**Table of Contents**

**List of Figures**

**List of Tables**

**Introduction**

_Who Am I Anyway?_

_Why WebRTC for Business People?_

_Why is this Report Open?_

**What is WebRTC?**

_What WebRTC?_

_Free_

_VoIP Developers_

_ORTC and WebRTC_

**WebRTC 's Job to be Done**

_Barriers of Entry for New Vendors_

_Reducing End User Friction_

_The Innovator 's Dilemma and WebRTC_

**Browser Support**

_Interoperability between Chrome and Firefox_

_Handling Safari and IE_

_Dealing with Mobile_

_WebRTC on Devices_

**WebRTC API Components**

_GetUserMedia_

_PeerConnection_

_DataChannel_

**Networking**

_P2P_

_Signaling_

_Firewall and NAT Traversal_

_Security_

**Requested Features**

_Multipoint_

_Recording_

_Interoperability_

**WebRTC vs. the World**

_Anatomy of VoIP Solutions_

_H.323 and SIP_

_Flash_

_" Proprietary"_

_Vidyo_

**WebRTC Hype**

**The WebRTC Ecosystem**

_The 5 Uses of WebRTC_

**WebRTC Use Cases by Verticals**

_Tooling_

_Video Conferencing_

_Telecommunications_

_Customer Service & Support_

_Expert Marketplace_

_Telehealth_

_Gaming_

_Social Networking and Consumer VoIP_

_Streaming and Content Delivery_

_Other_

_The Missing Verticals_

**Recommendations**

**Appendix A: Online Resources**

_Blogs_

_Communities_

**Appendix B: Choosing a WebRTC API Platform report**

**Appendix C: Finding out More**

**Appendix D: About Kandy**

**Appendix E: Kandy Usage Scenarios**

## List of Figures

Figure 1: The innovator's dilemma and WebRTC

Figure 2: Major milestones of WebRTC support in browsers

Figure 3: Browser downloads on Android

Figure 4: Chat session between Web browsers with and without WebRTC

Figure 5: WebRTC media traffic with and without a TURN server

Figure 6: Anatomy of VoIP - the 4 core components of any VoIP solution

Figure 7: Developers interest in WebRTC over time

Figure 8: Social network interest in WebRTC over time

Figure 9: Types of vendors in the WebRTC ecosystem

Figure 10: Growth pattern in web APIs

Figure 11: The WebRTC value chain and the 2nd market

## List of Tables

Table 1: Browsers support for WebRTC

Table 2: Comparison of WebRTC to other prominent VoIP protocols (SIP and H.323)

## Introduction

### Who Am I Anyway?

My name is Tsahi Levent-Levi. I am a developer at heart. I have been working in the telecom and VoIP/UC industries of the past 15 years (and counting) in various roles: from a developer, to project manager, product manager and CTO. Most of that time, I was dealing with signaling and media products that were licensed to other developers who built their own products with them. This gives me a broad view of the market and an understanding of the challenges and opportunities that exist in the domain of VoIP.

I came across WebRTC when it was first announced by Google and saw the potential in it. Since then, I have been watching the WebRTC space closely, consulting about it and writing about it on my blog: BlogGeek.me. From a hobby it became a "profession".

### Why WebRTC for Business People?

WebRTC is going to be transformative to the way we think about digital communication, and there are already a lot of resources out there. But most of the information is geared towards developers with very little provided to inform the entrepreneur or the product manager on what can be done with WebRTC.

The fact that WebRTC is evolving with every passing day, coupled with the FUD (Fear, Uncertainty and Doubt) that is spread by incumbent players makes it hard to make business decisions related to WebRTC.

This research paper comes to serve this purpose of explaining what WebRTC is, what it can and can't do, outlining the ecosystem around WebRTC and provide a healthy dose of vendors who have already taken the plunge with WebRTC and have built a business around it. At the end of each chapter, you will find links for extra reading material - some from my own writing and some from bright minds from around the web. At times, the same link will appear in more than a single chapter.

### Why is this Report Open?

Last year I took the time to write and publish this report. At the time, I decided to place it as a paid report on my website.

People purchased it and the feedback I received was good, but many stated it was too pricy for them. I have been contemplating this problem ever since. On one hand, this report contains valuable information, so I'd like to get paid for the work done. On the other hand, I really believe in the transformative nature of WebRTC and want to get the concepts it contains to as large an audience as I can.

Which led me to Kandy, who were kind enough to sponsor it so that anyone can pick it up and read it freely.

Since it has been over a year from the initial publication of the report, things had to change and updated a bit - both to fit the changes in the market as well as to fit better my own experiences and understanding of WebRTC. This report that you are now reading has been updated, and hopefully it is even better than the original one.

I'd like to thank the Kandy team for sponsoring this report.

## What is WebRTC?

WebRTC stands for Web Real-Time Communication. In essence, it is the fusion of two separate branches in technology: VoIP and the web.

VoIP, short for Voice over IP, is a set of technologies and techniques that enable sending media (usually voice and video) over an internet connection. Up until the introduction of WebRTC, VoIP lived within its own ecosystem silo, next to the booming Internet we are accessing daily via web browsers.

WebRTC comes to connect VoIP into our browsers, and by that, into websites and mobile apps. It does that by offering a thin layer of Javascript APIs that are implemented by modern web browsers, and are part of the HTML5 specification.

This means that now every web developer can add real time communication capabilities to his website or web application.

  | _Further Reading:_ 001 - bloggeek.me/ref/biz001/

  The history of WebRTC inside Google [Quora]

  Introduction to WebRTC [VisionMobile]

  The hurdles involved in using WebRTC

---|---

Two important aspects of WebRTC:

  It is free

  It changes the definition of VoIP developers

Together, they lower the barrier of entry for communication services to a level that enables use cases that were always required but never fulfilled by previous technologies.

### What WebRTC?

The term WebRTC in itself is a bit misleading, as it refers to two separate things at the same time:

1. WebRTC the specification

2. WebRTC the open source project

Both notions for WebRTC are used interchangeably most of the time and it is important you know the distinction between the two.

#### 1. WebRTC the Specification

WebRTC is a specification that is being standardized at the W3C and the IETF.

The specification deals with:

  What goes "on the wire" - what is sent through the network, so that two WebRTC-capable applications can interact with each other

  What are the APIs that utilize the functionality itself - the defined Java Script API that is located "on top" of WebRTC

The standardization of the first version of WebRTC hasn't finalized yet, which detracts incumbents and telecom vendors from adopting it. That said, there are still hundreds of vendors who are using WebRTC today, ignoring the transient state WebRTC is in today.

#### 2. WebRTC the Open Source Project

WebRTC is also an open source project. When Google first announced WebRTC, it was just an open source project located in its own website.

Google made it clear their intention was to standardize WebRTC and embed it into browsers. To that end, they donated the code to the community under a very permissive open source license.

As an open source project, WebRTC is quite a powerful piece of code that anyone can adopt and use in any way he sees fit - with or without relation to the fact that there is a WebRTC specification.

Ericsson recently announced its own WebRTC open source project called openWebRTC. How popular this project will be is yet to be seen.

### Free

WebRTC is free in every possible aspect.

1. It is packaged as an open source project and licensed under the permissive BSD license. Past implementations of similar technologies were either provided under a proprietary license that had to be purchased or under more restrictive open source licenses which wasn't palatable for a lot of vendors.

2. It supports and promotes free codecs which don't require any royalty payments for patent licenses. Codecs usually require multiple payments to use, starting from a license fee of a vendor and royalties based on quantities sold. This poses a financial barrier for adoption as well as a hassle when each quarter licensing fees needs to be recalculated and paid for.

  | _Further Reading:_ 002 - bloggeek.me/ref/biz002/

  WebRTC's Job to be done [UC Strategies]

  Codec wars in WebRTC around the mandatory codec

  Is there a future for optional codecs in WebRTC?

  The future video codec: H.265 versus VP9

---|---

This allows developers to repurpose WebRTC and its components in every possible mean:

  Porting it to operating systems and environments where similar media processing capabilities are necessary

  Using it in large scale deployments where the number of endpoints is considerable and the payment from each customer is low (most Over-The-Top solutions today)

  Adopting smaller modules out of WebRTC and using them alone. This is true especially to WebRTC's echo canceller and codec implementations

Later chapters in the area of use cases will show how different vendors and entrepreneurs are wielding the power of WebRTC.

### VoIP Developers

Developing VoIP capabilities is far from easy. It requires engineers in specific disciplines. VoIP projects are usually built by teams with 10 developers or more, dealing with aspects of codec integration, media engine development and fine tuning, operating system porting and interoperability testing. While some of these capabilities can always be outsourced or licensed, there are costs and time involved.

WebRTC is not just a specification. It was created from company acquisitions that Google has made recently. As such, it isn't just a "pet project" of a couple of developers but a commercial grade package.

With that in mind, you can see how WebRTC enables more developers to use VoIP related capabilities, but it doesn't stop there. The most important aspect of it is that addition of Javascript APIs and integration of WebRTC into the browser.

This changes the game for communication developers considerably:

  It changes the type of communication developers from C/C++ and Java developers to web and Javascript developers. This opens up the field to a considerably larger audience of developers, but also changes the mindset of these developers. You can think of it as a transition from waterfall development to agile development techniques

  It makes the browser the endpoint or engine that gets used. This reduces the hassles of issues such as security patches, upgrades and interoperability - nonfunctional aspects of development that takes time and money to deal with properly

The change in developers also means a change in focus - from the need to focus on how to implement a solution with high media quality, to a focus on the service being developed and the user experience it provides.

  | _Further Reading:_ 003 - bloggeek.me/ref/biz003/

  WebRTC is for web developers and not VoIP developers [NoJitter]

---|---

### ORTC and WebRTC

You might have heard of CU-RTC-Web or about ORTC.

CU-RTC-Web was a competing specification proposed by Microsoft. It was ignored in many ways by the IETF during the standardization work done on WebRTC. It later on merged with another proposal known as ORTC - Object RTC.

There is not enough clarity of the market as to the difference between the two: ORTC and WebRTC.

ORTC is a proposal of a new API façade for WebRTC. One that provides lower level capabilities for developers, enhancing the types of use cases that can be covered with WebRTC. It is also an API façade that lets go of the notion of SDP and Offer-Answer procedures that are used in WebRTC today and are part of the legacy baggage WebRTC brings with it due to its VoIP related origin.

ORTC is aimed towards making it easier for web developers to use WebRTC and manipulate the media streams. It is planned as an addition to WebRTC and not a competing specification.

It is assumed that once ORTC is finalized, existing browsers supporting WebRTC will add ORTC support.

ORTC is handled by the IETF in its own ORTC Community Group, where the lead is taken today by Microsoft and Google - along with 70 other vendors and individuals.

For planning purposes, you can view ORTC as WebRTC 1.1 - an evolution of the WebRTC specification.

## WebRTC's Job to be Done

If we look at WebRTC from Clayton Christensen's "Job to be Done" theory in book The Innovator's Solution, then what we are aiming for is to think less about market segments and more about the jobs customers want to do.

In the case of WebRTC, the "customers" can be viewed as developers and services who need real-time communication capabilities. For them, the job to be done can be split into two aspects:

1. Reducing their costs - their barrier of entry

2. Reducing the friction for end users using their communication capabilities

### Barriers of Entry for New Vendors

As an open source project with a permissible license, WebRTC offers a huge head-start for developers. It brings them immediate value of around 50,000-200,000 USD - the cost of a commercial media engine.

Coupled with availability through browsers on multiple operating systems and across mobile devices, this brings the development and testing costs down to a point where it makes sense to start using it.

This reduction in barrier of entry brings with it 3 distinct changes in the market:

1. More vendors and developers are looking at using real time communications

2. Use cases that had no reason economically to exist before, now make business sense with an ROI behind them

3. New business models are being experimented with

### Reducing End User Friction

As a browser capability, WebRTC enables the web to be much more interactive and capable. Digital storefronts and support services can now include the ability to communicate and "dial" right from within the website. This reduces the friction with the end users, and increases their chance of using the service more.

There are many different ways in which vendors are exploiting this capability:

  Adding and acting from context coupled with the request to communicate right from the website

  Enabling users to stay in the website without going for their phone to dial for service

  Adding capabilities to social interactions from within the same service, not "losing" the users to other services such as Skype

  Empowering contact center agents to work from homes and cafe shops without the need for any additional installations or setup

This reduction in friction has the potential of increasing the value of the service employing WebRTC.

### The Innovator's Dilemma and WebRTC

WebRTC fits into the classic Innovator's Dilemma. Wikipedia sums the Innovator's Dilemma rather nicely:

First published in 1997, Christensen's book suggests that successful companies can put too much emphasis on customers' current needs, and fail to adopt new technology or business models that will meet customers' unstated or future needs; he argues that such companies will eventually fall behind.

Displayed as a graph, the innovator's dilemma is represented as the market's demand versus the progress of a sustaining as well as a disruptive technology.

**Figure 1: The innovator 's dilemma and WebRTC**

In our case, WebRTC is the disruptive technology.

WebRTC is similar to current day VoIP, but at the same time very different:

  It targets a different type and set of developers

  It reduces barrier of entry for developers and reduces friction for end users

  It relies on a different set of technologies in the backend

Incumbents faced with WebRTC, won't see the big difference between it and their current technology. This has the danger of making them complacent.

  | _Further Reading:_ 004 - bloggeek.me/ref/biz004/

  A WebRTC JTBD (Job to be Done) Weekend

  WebRTC JTBD: Reducing Barriers of Entry

  WebRTC JTBD: Reducing End Customer Friction

  Who's a WebRTC Vendor? The BlogGeek.me WebRTC Litmus Test

---|---

## Browser Support

WebRTC is an evolving standard. It started in 2011 and since then, it has progressed faster than any earlier VoIP protocol - both in its specification as well as in availability of implementations. That said, there are differences in which parts of WebRTC browsers implement, if at all, and availability of WebRTC in mobile browsers is patchy at best.

The diagram below gives a short historic view into the progress of WebRTC implementation across the main browsers supporting it: Chrome, Firefox and Opera

**Figure 2: Major milestones of WebRTC support in browsers**

As you can see, browsers are updated frequently, filling in gaps in the support of certain WebRTC aspects. The table below provides the current state of affair:

**Table 1: Browsers support for WebRTC**

The table indicates two important aspects of WebRTC adoption:

1. The dominant players are Google Chrome and Mozilla Firefox. Apple Safari and Microsoft Internet Explorer are not taking part in the adoption of WebRTC, though Microsoft announced plans to adopt it in the future

2. Support is mobile is painfully lacking for iOS

In the next subchapters I will indicate what solutions, if any, are available for developers.

  | _Further Reading:_ 005 - bloggeek.me/ref/biz005/

  Up to date browser support of WebRTC [&yet]

  Overview of browsers support of WebRTC [NoJitter]

  WebRTC: Who Will Surrender First? Apple or Microsoft?

  Decrypting Google's Roadmap for WebRTC

---|---

### Interoperability between Chrome and Firefox

Not everything is equally implemented in both Chrome and Firefox. That is to be expected this early in the game, with new browser version being released every other month. It should also be noted that there are two important aspects that WebRTC brings that weren't available before:

1. **Interoperability is less of an issue** - prior to WebRTC, 10's of different implementations needed to be tested against each other for interoperability. I attended such interoperability events - they are a lot of fun and usually packed full with vendors testing their applications and devices against each other. With WebRTC, we are down to a handful of browsers that need to deal with the real headache of interoperability. So consider this one mostly "done", while expecting the same incompatibilities you will find with other HTML5 features across browsers.

2. **Interoperability bugs get fixed faster** - with browsers being updated regularly and automatically these days, you can expect known interoperability issues to be solved by browser vendors rather fast, and reach end users faster than any other VoIP solution out there.

While the basics of WebRTC are supported well by both Chrome and Firefox, any deviation from the basics may get to the realm of an unimplemented feature of WebRTC in one of the browsers or a simple mismatch between them. Plan for it in advance and make sure to try any out of the ordinary aspect of your service as early as possible on both browsers.

### Handling Safari and IE

Apple and Microsoft are staying at the sidelines when it comes to WebRTC. While both companies are showing interest in WebRTC, nothing is publicly known of their plans.

To make things even harder to deal with, Google has discontinued their Chrome Frame plugin for Internet Explorer this year. Chrome Frame enabled the use of a single plugin for IE that enabled any version of the IE browser to support the latest HTML5 features, WebRTC included. With this discontinuation, the ability to use IE with an official Google support for WebRTC on it has become impossible.

This situation leaves developers at a disadvantage if they select WebRTC. If you plan on starting a WebRTC-based service, you will need to take this into account with one of 4 options available to you:

1. **Support only Chrome and Firefox**. Anyone trying to access your service via IE or Safari can receive an indication that they need to switch a browser. To see if this fits your service, you need to research into the browser use in the region you plan to launch your service and your specific target audience. Large enterprises, for example, might not allow running anything other than IE on their employee machines.

2. **Write your own plugin**. You can wrap WebRTC as a plugin and have it installed when users access your service from IE or Safari. This adds some friction to using your service, but might be a better solution than deciding to ignore such users. Again, there are cases where the use of plugins will be forbidden, mainly in large enterprises.

3. **Use a free plugin**. There are several plugins available on the market today. The two most known ones are Temasys' free plugin for IE and Safari; and Priologic's open source plugin for IE. Same restrictions as the option of writing your own plugin apply here.

4. **Don 't use WebRTC**. WebRTC is great, but it might not be for you. If your service mandates the use of IE without use of plugins, then WebRTC cannot be used at this point in time. Just select another technology, a different target market or a different service.

  | _Further Reading:_ 006 - bloggeek.me/ref/biz006/

  How to get support into old browsers? [Disruptive Analysis]

  The future of WebRTC in Internet Explorer

  WebRTC Plugin: Temasys or easyRTC? Free or Open Source?

  8 Things to Consider when Selecting a WebRTC Plugin

---|---

### Dealing with Mobile

Mobile poses an even larger challenge with WebRTC:

  On mobile, browsers are not the main channel for user consumption. Applications are

  Only Chrome and Firefox in their mobile versions support WebRTC, and that on Android devices only - no iOS devices are supported at this point

**For most of the use cases on mobile, the requirement will be to wrap WebRTC inside an application instead of using the browser as the point of access.**

If you look at the download numbers of these two browsers and compare them to the number of activations of Android devices and other downloadable mobile browsers, the following picture emerges:

**Figure 3: Browser downloads on Android**

While browser downloads on Android have significantly improved in the past year, there is still a long way to go. The figure above brings with it several insights:

  Chrome browser is hugely popular on Android because it is being installed by default on devices since the Android KitKat release

  Other browsers aren't fairing as well - people don't usually install browsers on their devices

  In June 2014, Google announced 300 million monthly users of Chrome on mobile. That includes both Android and iOS. This is below over 500 million downloads of Chrome on Android, showing that people don't necessarily use the browser on their device

  Games and communication apps are more popular than browsers - something true for apps in general

That in itself isn't bad news, depending on the service you have in mind. Current behavior patterns on mobile show that consumption of online services comes from apps and not directly through the web browser: Flurry Analytics estimates that 86% of the time spent on iOS and Android is on Apps, while only 14% is spent in web browsers. Most amount of the Apps time is spent on Gaming, Facebook and Social Messaging.

An additional advantage of creating an application for mobile as opposed to using the browser directly, is the opportunity to address challenges posed by the mobile environment. These include network changes (switch between WiFi and cellular and no coverage, camera rotation, interruptions from incoming native calls, etc.

Using the controlled environment of an application can assist in overcoming these issues, but require the care and attention of the developer or the 3td party SDK used for the task.

Check how your service gets consumed on mobile. If users are expected to "bump" into it when browsing the internet or by specifically going to your service via an app. Going via an app means you can use WebRTC in its ported form, wrapped inside an application - something that several vendors have already done. Assuming you want WebRTC to be embedded in your app, there are three different options open for you:

1. Port and integrate WebRTC on your own for the mobile devices you plan to support. Vonage, for example, has taken this route

2. License a ported WebRTC stack from vendors offering such a service. There are multiple WebRTC outsourcing outfits today, and some of them offer porting services

3. Use a 3rd party WebRTC API platform that already have their offering ported to a mobile SDK.

  | _Further Reading:_ 007 - bloggeek.me/ref/biz007/

  Predictions on annual app downloads on app stores [Gartner]

  Where is WebRTC positions on mobile platforms

  The challenges of porting WebRTC to mobile devices

  Flash to WebRTC: Why Gruveo Finally Converted

  Choosing a WebRTC API Platform report

---|---

### WebRTC on Devices

An additional opportunity of utilizing WebRTC is in other devices - set-top boxes, video room systems and Chromecast-like dongles are some examples.

In this case, a device or component that needs to be able to process and send/receive media can achieve that by a porting WebRTC and embedding it within the device.

There are two main reasons to select WebRTC for these devices:

1. WebRTC has a very permissive open source license, making it easy to use as the basis of a generic media processing component. It has also been proven to be portable numerous times already.

2. By using WebRTC embedded in the device makes it easy to interact with these devices from other mobile devices, laptops and browsers.

While some may complain that WebRTC isn't a stable standard yet, using it may prove the best approach for those who want to limit vendor lock-in for their media processing components and systems.

  | _Further Reading:_ 008 - bloggeek.me/ref/biz008/

  Chromecast as a predicate of M2M use of WebRTC

  Motion detecting baby monitor with WebRTC [webrtcH4cKS]

  Comcast Getting it Right with WebRTC: Opts for Video Streaming over Video Chatting

---|---

## WebRTC API Components

WebRTC APIs are designed around 3 main objects. These are:

  **GetUserMedia** , enabling access to the cameras and microphones of the device

  **PeerConnection** , taking care of all media transport activities in WebRTC

  **DataChannel** , dealing with proprietary data transmission between clients

### GetUserMedia

The Get User Media APIs enable capturing the input devices: camera and microphone, giving access to them via JavaScript. To get over privacy issues, when these APIs are called in a website, the user is asked for permission to give such access.

This API can be viewed as external to WebRTC - in a way, it doesn't deal with communication at all. That said, Get User Media opens up possibilities for a wide variety of services - from photo-booth experiences to capturing a user's photo when onboarding a new service (this is what MailChimp does when you register a new account or edit your profile).

  | _Further Reading:_ 009 - bloggeek.me/ref/biz009/

  HTML5 demos making use of GetUserMedia [Shiny Demos]

  Face detection with GetUserMedia [Raymond Camden]

  What if Microsoft was Really Serious about WebRTC

---|---

### PeerConnection

At the heart of WebRTC lies the Peer Connection. This is where most of WebRTC's VoIP implementation lies.

The PeerConnection API holds inside it everything: SDP negotiation, media sending and receiving, handling network issues such as packet losses, codec implementations, NAT traversal, etc. The API itself wraps it all in a simple package that enables adding media streams into a peer connection, negotiating capabilities and NAT traversal.

Most vendors focus on adding value by using the PeerConnection APIs.

  | _Further Reading:_ 010 - bloggeek.me/ref/biz010/

  An example of using PeerConnection [Big Nerd Ranch]

---|---

### DataChannel

The Data Channel can be considered the "jack in a box" of WebRTC. It is a generic interface that can carry any type of data - media or otherwise - between 2 WebRTC devices.

While doing that in applications is rather straightforward, WebRTC offers a solid infrastructure that usually isn't available for developers, along with the fact that it offers it inside a web browser in a real P2P fashion:

1. Ability to send data either reliably or unreliably, giving the flexibility for developers to choose what fits their needs without adding additional applicative layers

2. Same security and NAT traversal capabilities used for sending media is extended to the data channel as well

3. P2P support within the web browser for any generic data

4. Adheres to the network characteristics by limiting or extending bandwidth to what is available dynamically

These aspects make the Data Channel an unknown factor in what developers can do. Some of the early implementations that have adopted the data channel include:

  Assisted P2P video streaming, similar to how BitTorrent is working

  CDN (Content Delivery Network) P2P, where multiple users browsing the same website share the resources and images they download from web pages amongst themselves directly

  Online file sharing

  Gaming and chat applications, where low latency is required

  | _Further Reading:_ 011 - bloggeek.me/ref/biz011/

  Introduction to broadcasting over IP

  Sending files using the DataChannel

  WebRTC's secret weapon is the data channel [Chris Kranky]

  7 Creative Uses of WebRTC's Data Channel

---|---

## Networking

WebRTC deals with networking much in the same way that other VoIP solutions treat them. The main difference you will find is that WebRTC leaves a lot less options for developers in certain areas; and in the case of WebRTC, fewer options means better solutions.

VoIP standardization has suffered for over a decade from over-complexity. Put simply, if something can be done with a specific VoIP protocol, it can probably be done in multiple ways, making development, testing and interoperability a real headache.

WebRTC took the route of as little options as possible when it comes to issues of how to implement the basics. This chapter covers several areas where such decisions were made, providing a glimpse into the mindset behind WebRTC.

While WebRTC is based on existing specifications, it did divert from the "tried and true" of VoIP. In some cases, it selected to support specifications that weren't popular or in wide use in the industry. In other cases, it tweaked and improved the existing specifications to fit its own needs.

The topics covered here are:

  **P2P** - the type and nature of the peer to peer that WebRTC provides

  **Signaling** - what role does signaling take in WebRTC

  **Firewall and NAT Traversal** - the mechanisms of NAT traversal supported by WebRTC

  **Security** - what is the security paradigm employed by WebRTC

### P2P

WebRTC is said to be a P2P protocol, by which it means that 2 peers connected via WebRTC get connected directly to each other. While that may well be true, there are several aspects of WebRTC's P2P nature that need clarification:

#### 1. WebRTC is no different than most VoIP solutions

WebRTC provides only the media path, and many of its predecessors use much the same techniques to send media directly between peers. In a way, there's nothing new in WebRTC's P2P nature when compared to SIP-based deployments or other proprietary deployments. As with other VoIP protocols, WebRTC can work P2P or via servers - it is up to the implementer (and the network conditions) to decide which architecture is used.

#### 2. WebRTC is the only P2P technology in web browsers

The main difference of WebRTC's P2P nature is within the web browser itself. Web browsers have been designed to allow communication between the web browsers to a server. Up until WebRTC, there was no way for one web browser to talk directly to anther web browser without the intermediation of a server. With WebRTC, that becomes possible

**Figure 4: Chat session between Web browsers with and without WebRTC**

#### 3. WebRTC may require media relay

While WebRTC offers a P2P solution, at times, it requires relaying the media itself via intermediary TURN servers. More on that in the next subchapter on NAT Traversal.

**Figure 5: WebRTC media traffic with and without a TURN server**

#### 4. WebRTC requires external signaling, which isn't P2P

While WebRTC offers a P2P solution, in order to reach another peer, there needs to be some centralized decision making processes that occur on the external signaling protocol that each service choose to adopt.

  | _Further Reading:_ 012 - bloggeek.me/ref/biz012/

  4 facts about WebRTC and P2P

  The role of the server in a WebRTC P2P service [vLine]

---|---

### Signaling

Signaling was specifically left out of WebRTC. There are those that see this as a positive decision while others believe that signaling needs to be added under the fold of WebRTC.

The reasons for not having signaling as part of WebRTC are various:

1. Adding signaling to the WebRTC specification would drag the process through standardization - there are more existing options for VoIP signaling than there is for media processing

2. WebRTC can be hooked up to use different signaling protocols today. Selecting one mechanism, either existing or new, would mean reducing the use cases and deployments where WebRTC can bring value

3. VoIP signaling is good for VoIP. WebRTC adds a web component that was always missing in VoIP, where a lot of services already have some kind of signaling. Being able to accommodate these services made sense

The only component within WebRTC that does deal with signaling is SDP. SDP stands for "Session Description Protocol" and is used for describing multimedia session capabilities and negotiating them. It is a critical first step towards connecting media streams.

SDP is used in SIP, and as with other VoIP related issues, there are those that believe it isn't suitable for WebRTC while others see it as sufficient.

SDP can be considered as a "necessary evil" which will be part of WebRTC for years to come until a better/different solution is negotiated in the standardization bodies.

A more detailed discussion on the various signaling options can be found in the next chapter.

  | _Further Reading:_ 013 - bloggeek.me/ref/biz013/

  The death of signaling as we know it

  Why signaling isn't important anymore

  Node.js at the service of WebRTC

  Why we need signaling for WebRTC [WebRTC.is]

  Signaling options for WebRTC applications [webrtcH4cKS]

  SDP: Session Description Protocol RFC [IETF]

---|---

### Firewall and NAT Traversal

To get media flowing from one browser to another, the media packets may need to pass through NAT devices. NATs are Network Address Translators. They are deployed everywhere - in our home DSL boxes, enterprise boundaries and in our service providers' backend. They have various roles and the come in different shapes and sizes. To that, enterprises and home devices add Firewalls, preventing unauthorized access to the network - these are unaware of VoIP and WebRTC related traffic and block it by default.

In most daily scenarios, our devices have local IP addresses - ones that cannot be used globally. When we access the web, the NAT device replaces the local IP address of our requests with a public IP address. This process is done in different ways by different NAT devices. This causes headaches for those who need to pass NATs to communicate - especially when that communication is bidirectional in nature.

The main challenge with NAT traversal in WebRTC is the fact that it is a new challenge for web developers, who are accustomed to having data pass through NATs and firewalls seamlessly for web traffic. They are unaware to the intricacies, challenges and cost of dealing with NATs in the real-time communications domain.

The selected solution for WebRTC in the area of NAT traversal is the use of ICE, which in turn makes use of STUN and TURN. These are the same threesome of protocols used by SIP. As with other such similarities, here too WebRTC takes the approach of using the latest possible drafts and ideas and mandating them for use with WebRTC.

Trying not to dive into details, here is a short explanation on each of the 3 specifications used in WebRTC for NAT traversal:

1. **STUN** - provides means for the WebRTC client to find its own public IP address simply by asking an external STUN server. Knowing this information in many cases is enough to get a WebRTC session to connect

2. **TURN** - when STUN fails, TURN can be used to relay all media between the WebRTC clients. This requires more bandwidth and processing power from the backend, but it gets more calls to connect

3. **ICE** - ICE is in charge in orchestrating this whole show - deciding which route and NAT traversal mechanism best fits a given moment in time for the session

At the end of the day, STUN and TURN servers need to be deployed; which is a hassle. Developers use multiple solutions for such a case:

1. Decide to deploy only with STUN support, and use publicly known STUN server addresses (hoping they will not be moved or removed)

2. Deploy with STUN and TURN, installing and maintaining such servers as part of the operation

3. Use third party SaaS provider for NAT traversal, who provide paid STUN and TURN servers access

It should be noted, that there are cases where none of the techniques used by WebRTC can successfully get a session to connect. This usually happens when the endpoints in question are within enterprises with strict security rules. There are multiple drafts proposed to the IETF to address this issue - mainly by tunneling media traffic over web sockets.

  | _Further Reading:_ 014 - bloggeek.me/ref/biz014/

  Introduction to NAT Traversal in WebRTC [webrtcHacks]

  An overview of NAT Traversal by AudioCodes [SlideShare]

  ICE always tastes better when it trickles

  ICE: Interactive Connectivity Establishment RFC [IETF]

---|---

### Security

Security is part and parcel of WebRTC. Where other VoIP protocols have taken the route of allowing security as an optional feature (usually as an add-on years after the original standard was specified), WebRTC has no means of sending media without having it encrypted.

This approach reduces the number of options and decisions developers have to make about the way they use WebRTC and results in a robust solution suitable for modern communication.

There are several important aspects to remember when dealing with WebRTC security:

1. WebRTC uses SRTP and AES encryption for the media being sent. These are both widely used and mature specifications

2. While media communication is secure with WebRTC, the signaling part isn't. It is up to the developer doing the integration with a specific signaling solution to take care of protecting that path - it can be as "easy" as placing that communication over HTTPS/TLS

3. WebRTC in the browser have an additional factor of security - any security holes found within WebRTC are handled by the browser vendors. While this reduces the control of implementers, browser vendors have been very responsive to date in closing known security holes much faster than vendors in other domains

4. With the current awareness around security and privacy due to the Snowden Affair and talks about the NSA practices with both carriers and web vendors, WebRTC is sometimes touted as a possible solution due to its secured nature. That is usually overstated as WebRTC is a technology that can be used in decentralized scenarios but also in centralized ones.

Never take security for granted, but keep in mind that WebRTC brings with it top notch capabilities in security that are not readily available elsewhere.

  | _Further Reading:_ 015 - bloggeek.me/ref/biz015/

  Why WebRTC is the most secure VoIP technology

  How security and privacy may be threatened by WebRTC

  What can WebRTC tell you about your local network

---|---

## Requested Features

WebRTC is a relatively new technology. It has been with us for 2 years only and has already amassed a nice number of vendors around it. There are a lot of gaps in this technology for those who wish to employ it for various use cases. These can be seen as hurdles to some and as opportunities to others.

In this chapter, I will outline the main pain points vendors are expressing today with WebRTC.

  | _Further Reading:_ 016 - bloggeek.me/ref/biz016/

  What developers have to say about their WebRTC needs

  WebRTC infrastructure is tricky

  8 Gaps Left by Google in WebRTC

---|---

### Multipoint

Support for multipoint video calling is an issue for developers. For those in need for such a feature in their use case, make sure to find a solid architectural solution.

Multipoint support means the ability to have more than 2 participants within the same session. The common practice today with WebRTC services is to build video conferences of up to 4 participants by directly connecting each browser to all other browsers. This practice requires processing power and bandwidth in the endpoints, which means it doesn't scale well.

The other option is to use a central routing/switching/transcoding unit in the backend that takes care of all media mixing for the participants. Such solutions vary in size and price, so if you need to go that route, start by writing down the use case and flow you need to support before searching for a solution that fits.

  | _Further Reading:_ 017 - bloggeek.me/ref/biz017/

  5 part series on multipoint topologies in WebRTC

  WebRTC Multipoint: Mix, Mesh or Route?

---|---

### Recording

Many communication related use case require the ability to record the session.

While recording can be done on the browser side to some extent, its real value and potential can only be realized when done on the server side. Most vendors and services today don't offer a recording capability, but have expressed interest in adding one.

Recording in WebRTC on the server side can be done in one of two ways:

1. Route the session through a server instead of P2P and have the server side handle the recording. This requires more processing power and bandwidth on the server side to manage, but reduces the upload bandwidth as well as processing power required from the client side

2. Have the client's JavaScript code send the media to an additional participant which is the recording server. This makes it easier to decouple the recording capability from the signaling and media paths of the sessions, but requires more upload bandwidth as well as processing power from the client side, so it might not fit all use cases and all geographies

It is important to remember that recording doesn't come alone: it also requires the ability to archive and store the media sessions as well as retrieving them. The retrieval part can be rather tricky, as it will depend on the devices and methods in which you plan on offering playback capabilities for the sessions - enabling retrieval on Internet Explorer or direct streaming to mobile devices will require transcoding the sessions either in advance or on demand.

  | _Further Reading:_ 018 - bloggeek.me/ref/biz018/

  Why something as simple as recording is complex [NoJitter]

---|---

### Interoperability

WebRTC can live in a flux, where a specific use case can live in its own island. In such cases, there is no external ecosystem you need to connect with. In some other use cases, connectivity to other domains is mandatory - things like integrating with an existing PBX system or to the global PSTN are examples of this.

Such a requirement around connectivity is usually referred to as interoperability. Interoperability in WebRTC happens in three separate domains, each with its own challenges:

1. **Signaling** - adding signaling on top of WebRTC isn't always possible and has its own nuances. SIP and H.323, for example, are challenging as WebRTC signaling protocols:

a. Accommodating SIP isn't supposed to be hard, but it does have its nuances **:** the SDP is managed slightly different, and many of the RFCs and features that are mandated in the media streams for WebRTC are considered new and optional for SIP. Bridging the gap requires careful planning and awareness to the problem

b. H.323 cannot be glued on top of WebRTC within the browser itself. This may be true with other signaling protocols as well. Providing connectivity between WebRTC clients to an H.323 deployment is not trivial

2. **Networking** - WebRTC comes with mandated security as well as support for the latest RFCs (ability to send multiplex media on the same network port, etc.). It means that existing and legacy deployments can't directly interoperate with WebRTC without some mediation in-between.

3. **Codecs** - Some of The codecs selected for WebRTC are different than those used in other VoIP deployments. This means that connectivity can occur only by transcoding the media between WebRTC and external networks.

These challenges are usually solved by mediation mechanisms, where the most common ones used are gateways and session border controllers (SBC). There are numerous vendors offering this equipment in different shapes and sizes, so finding one that fits your needs without the hassles of developing it from scratch is possible.

  | _Further Reading:_ 019 - bloggeek.me/ref/biz019/

  Multiple vendors announce gateways for WebRTC

  The necessity of gateways

---|---

## WebRTC vs. the World

WebRTC doesn't exist in a void. It is a relatively new entrant to an established VoIP market. It bears a lot of resemblance to other technologies. If you are in search for a technology to fit a service you have in mind to create, it is important to understand the commonalities as well as the differences that WebRTC brings with it.

First step in this understanding is to know the anatomy of VoIP solutions.

### Anatomy of VoIP Solutions

A VoIP product is usually based on 4 core components:

**Figure 6: Anatomy of VoIP - the 4 core components of any VoIP solution**

This section will review each of these components and how WebRTC handles them.

#### Codecs

A full HD video requires 1920x1080 pixels per frame with 30 frames per second. If each pixel requires 24 bits of color, this gets you to about 186MB of data per second - an impossibly large amount of data even for 1Gb networks.

To that end, codecs (code-decode) are used. Their sole purpose is to encode (=compress) video and voice signals prior to sending them and to decode (=decompress) these signals once received. For VoIP, these codecs are lossy - they lose information when they encode to save on space, usually by making assumptions around the human eye and the human ear and also by external restrictions such as the quality required or the bandwidth available.

WebRTC comes with 2 mandatory codecs:

1. **G.711** , the baseline voice codec. Offers narrowband voice quality, without any compression or resiliency as part of the codec. Ubiquitous in its availability in existing products.

2. **Opus** , a top of the line wideband codec that made its first appearance in WebRTC and is now trickling to other VoIP products as well.

There is an ongoing debate over the mandatory video codec in WebRTC.

  Google has taken the stance of supporting **VP8** and is working on adding **VP9** to Chrome. These are "proprietary" video codec of Google

  Microsoft and Apple are gravitating towards **H.264** , the standard video codec used everywhere today

  Cisco has released an open H.264 implementation, paid for in terms of royalties. It has aligned with Mozilla who are supporting both VP8 and H.264

The main reason for VP8 and VP9 - royalty free codecs (as opposed to H.264 which is a royalty bearing codec).

Each VoIP product and protocol makes its own selection of mandatory and optional codecs, usually having multiple codecs supported to enhance the potential of interoperability.

Codecs bring 3 main challenges to developers:

1. Which codecs to select for a given product?

2. Who to license the codecs from to support a given use case and device types?

3. How to handle licensing terms and royalty payments, fitting it into the ROI equation

WebRTC reduces these challenges in a lot of the use cases, but not in all of them.

  | _Further Reading:_ 020 - bloggeek.me/ref/biz020/

  The need for a mandatory codec in WebRTC

  Does the future of WebRTC lie in VP9 or H.265

  H.265 may never happen [NoJitter]

  In favor of H.264 as a mandatory video codec [WebRTC.is]

  On Opus voice codec

  iPhone 6 FaceTime Supports H.265. Where is VP9 for WebRTC?

  Microsoft, IE, ORTC, WebRTC, Skype & H.264: Where to now?

---|---

#### Media processing

While codecs do a decent job, they are not enough. There are other aspects that need to be taken care of when it comes to sending media across networks. The two main ones are:

1. Networks aren't created equal, and what is being sent might not really be received on the other end, so someone needs to handle these things

2. There are local transient issues, such as echo between the microphone and the speakers of a device that needs to be cancelled, varying volumes from changing position of the speakers, etc.

These can all be wrapped into what I call "media processing". To that end, vendors will either self-develop or license "media engines" to do the work. Part of this module is straightforward implementations while other are based on best practices, heuristics and "black magic" that developers have placed into their code.

In the case of WebRTC, this is what that Google has acquired from GIPS and ended up open sourcing as parts of what WebRTC is. There are developers who simply rip media processing algorithms from WebRTC and integrate it into their own products where they see fit.

There are three main approaches to WebRTC when it comes to media processing, where different approaches may be selected when dealing with the client side part and the server side part of media processing:

1. **Use WebRTC as is** , relying on whatever the web browser (and in effect Google at this point in time) to deliver the quality necessary and handle the network impairments on its own

2. **Replace the innards of the media processing components of WebRTC** to provide a better experience in the given use case. This is done either on the server side or in closed applications on mobile or desktop where WebRTC can be controlled and modified. The things that people replace in these cases are:

a. Rate control mechanism, which handles the decision of how much bandwidth is available at any given point in time

b. The audio algorithms - things like echo cancellation, noise suppression and audio gain control

3. **Use WebRTC 's media processing components** in a totally different setting - treating it just like pieces of code to be repurposed elsewhere. More on this in the ecosystem chapter

#### Signaling

Now that we are able to send media from point A to point B, the question then becomes how A knows about B and how do they signal to each other their intents. That is done by using signaling protocols.

In the domain of VoIP, there are essentially 4 options:

1. **H.323** , an ITU protocol that is used mainly in video conferencing deployments with dwindling support for it

2. **SIP** , the IETF equivalent of H.323. Used everywhere these days

3. **XMPP** , another IETF protocol that started with presence and IM focus but has its own extensions for voice and video chat (Jingle)

4. **Proprietary** , where each vendor to its own. A good example to it is Skype

WebRTC decided not to deal with signaling at all and left that to implementers. The selection of the signaling protocol used will affect the capabilities you will be able to achieve and will usually be linked to the types of devices and ecosystems you wish to connect.

  | _Further Reading:_ 012 - bloggeek.me/ref/biz012/

  The death of signaling as we know it

  Why signaling isn't important anymore

  Node.js at the service of WebRTC

  Why we need signaling for WebRTC [WebRTC.is]

  Signaling options for WebRTC applications [webrtcH4cKS]

---|---

#### Infrastructure

Infrastructure is where VoIP service diverges from each other and where real differentiation happens. It is how VoIP clients get connected to back ends, what additional capabilities are provided just because there's infrastructure involved.

What WebRTC did was commoditize codecs, media processing and signaling - making them all a lot less relevant - and enabling vendors to focus on their infrastructure and use cases. This is why there are so many new use cases that WebRTC vendors are implementing that were technically possible before WebRTC but never touched - they required too much effort for the return they provide.

### H.323 and SIP

A lot of times when VoIP is mentioned, it refers to the H.323 and SIP protocols. While these protocols come to solve the same problem set and have similar philosophies and worldviews in a lot of areas, their markets are slightly different.

**Table 2: Comparison of WebRTC to other prominent VoIP protocols (SIP and H.323)**

H.323 controls a lot of the enterprise video conferencing market deployments, although its market share is probably diminishing; and SIP exist practically everywhere else, including in IMS deployments.

Both of these protocols use RTP to carry their media and optionally use SRTP - SRTP is mandatory in WebRTC. The media transport protocol of choice for WebRTC. On the NAT traversal and media negotiation front, WebRTC bears great resemblance to SIP while H.323 has its own protocols.

In the voice and video codecs, WebRTC differs greatly from SIP and H.323. While SIP and H.323 offer a wide variety of choice, that choice causes a lot of headache in interoperability of high quality codecs. For WebRTC, Google took the route of selecting specific codecs with the main focus being latest available technology coupled with royalty free business model. There is an ongoing debate in the industry whether a popular royalty bearing codec (H.264) should be used instead of VP8. While that debate isn't over, the majority of WebRTC services are using VP8 today.

On the API front, WebRTC offers a specific API that is used by web developers while SIP and H.323 are provided with different APIs in different languages from the various vendors.

H.323 and SIP don't live within the browser and using them requires applications to be developed, compiled, packaged and delivered as part of the service. That said, SIP is moving towards the web browser by introducing SIP over WebSockets; making it a suitable companion for WebRTC.

While WebRTC doesn't compete with these protocols, and can even be used and interoperate with them, it does pose a threat to them, simply because it doesn't mandate the use of any of them. Many developers today opt for using WebRTC with their own proprietary signaling implementation to reduce the complexities associated with SIP and H.323 signaling. By doing so, they shun the traditional VoIP world and its use cases to implement their narrow use case. This approach doesn't force sessions in WebRTC to adhere to the decade old telephony system and enables anyone, with or without VoIP experience, to use WebRTC with ease.

  | _Further Reading:_ 021 - bloggeek.me/ref/biz021/

  WebRTC is shifting signaling to XMPP and JS

  The rise of Java Script SIP implementations

---|---

### Flash

Flash was the only mechanism in the web browser where real time communication could occur prior to WebRTC. Flash brought with it several problems:

1. For a long time it supported only H.263 video codec, which was inferior. The end result was poor video quality

2. Flash only worked with a server - for all media transmission. This proves to be a barrier for many use cases and for experimentation by developers

3. It wasn't HTML. The tools required for development weren't as common place and as accessible as WebRTC is today

4. Its echo canceller was bad, which resulted poor voice quality in conversations conducted over the PC speakers

5. To a large extent, it was non-existent in smartphones and tablets. While that is due to Apple, its implementation on Android wasn't good enough

Many of the Flash based companies are now migrating towards WebRTC - either doing it purely by switching the technology or by providing both options: using WebRTC when possible and downgrading to Flash when WebRTC can't be used.

  | _Further Reading:_ 022 - bloggeek.me/ref/biz022/

  How WebRTC and Flash differ [SaleMove]

  Would you use WebRTC to Chat with Mom?

  Flash to WebRTC: Why Gruveo Finally Converted

---|---

### "Proprietary"

There are and will always be proprietary implementations. The most notable one today is Skype. For the past decade, Skype has provided VoIP solutions based on a proprietary signaling protocol. Even their selection of voice codecs wasn't reliant on best practices in the industry.

This approach has worked well for Skype, enabling them to overcome technical challenges that were debated in the standardization bodies. This gave them a head start on most other competitors who relied on standardized SIP or H.323.

Opting for the proprietary route comes with its own set of challenges - mainly the inability to tap to the external ecosystems to license components while focusing on the core business.

### Vidyo

Vidyo is mentioned here due to its recent announcement with Google around adding its SVC technology into VP9. VP9 is the predecessor of VP8. Google have already integrated VP9 decoder into Chrome for YouTube videos. They plan on introducing VP9 to WebRTC during 2015.

Vidyo is based on its own technology, where SVC takes a key part. SVC stands for Scalable Video Coding and it is a technique in which a video stream is encoded in layers - each layer adding more quality on top of the previous one. This layered approach allows sending different layers to different participants, based on the needs of the conference and the capabilities of the network and the devices. The end result is the ability to build more efficient multipoint video bridges.

This kind of technology makes sense for use cases where there are more than 2 participants. Managing the backend in such scenarios isn't trivial and this is why Vidyo went for the deal - it hopes to bank on the ability to use WebRTC in the browser directly for its customers and deployments without the need to install an application. For Google, this means a better video codec and less server computations for its Google Hangouts service.

  | _Further Reading:_ 023 - bloggeek.me/ref/biz023/

  Challenges and opportunities of Vidyo following the VP9 deal

  How Vidyo's deal affects the rest of the UC market [Talking Pointz]

  Google is targeting Skype with SVC deal [NoJitter]

  How Google is Disrupting the Enterprise Video Conferencing Market

---|---

## WebRTC Hype

There is no hype when it comes to WebRTC.

Pundits have been debating this for quite some time now, with varying opinions. I believe there isn't and wasn't any hype around WebRTC whatsoever.

When I started blogging about WebRTC about a year ago, I was alone in the field. Very little information and thought leadership could be found about WebRTC on the web. Since then, that has changed with individuals, vendors and media outlets now covering this space.

Any apparent hype being felt can be attributed to many reasons:

1. **WebRTC in a new technology**. As such, the process of understanding it that takes place these days in public on blogs look like hype for some: you will find few observations these days about where SIP belongs within the domain of VoIP, but a lot of writing about WebRTC's place in VoIP

2. **WebRTC deals with VoIP and web**. While VoIP belongs to a small set of developers within the communication market, WebRTC opens up that market to a distinctly larger set of developers. This increase in availability of communication technology seem to some like hype

3. **WebRTC reduces the barrier of entry**. Use cases that had no ROI up until WebRTC are now being introduced, enhancing the ways in which VoIP is use

In the past 8 months, I have collected data points indicating the interest around WebRTC.

**Figure 7: Developers interest in WebRTC over time**

The graph above illustrates three domains that are prime destinations for developers interested in WebRTC:

1. The Google group called discuss-webrtc

2. The number of github projects related to WebRTC

3. The number of questions around WebRTC on StackOverflow

**Figure 8: LinkedIn profiles related to WebRTC**

The graph above details the number of LinkedIn profiles that have WebRTC somewhere in their description. While this number is rather low, it is easy to see an upwards trend.

The results of these graph show a linear increase in interest - this is an indication that we are either before the real hype of WebRTC - or that no hype will happen with WebRTC at all.

  | _Further Reading:_ 024 - bloggeek.me/ref/biz024/

  There is no hype around WebRTC [NoJitter]

  Why WebRTC is overhyped [NoJitter]

  Why the hype around WebRTC doesn't matter [NoJitter]

  Gartner Hype Cycle, WebRTC Not Included [The New Dial Tone]

  WebRTC on the Rise? Geek Questions Hold the Answer [NoJitter]

---|---

## The WebRTC Ecosystem

The WebRTC ecosystem is built of a large set of vendors, startups and individuals; all with their own agendas. This chapter tries to analyze the WebRTC ecosystem from several angles, each providing a different prism into WebRTC.

### The 5 Uses of WebRTC

If I had to split the ecosystem and categorize vendor on the types of usage they make of WebRTC, I'd be splitting them into 5 broad categories: Supporting, Using, Porting, Repurposing and Adopting.

**Figure 9: Types of vendors in the WebRTC ecosystem**

Before I go into detail about the categories there are a few things to keep in mind:

  A vendor can be in multiple categories at the same time

  Similar vendors chose a different category to belong to. The choice changes their core competencies and basis of competition to some extent

#### WebRTC Core

The supporting role at the heart of WebRTC belongs to vendors who contribute to it directly. Here you will find Google and Mozilla, who are embedding WebRTC into their browsers, but also companies like Vidyo who are adding SVC technologies into future WebRTC releases.

The amount of vendors in this area is small, as they require extensive knowledge into the inner-workings of WebRTC. This role comes with little upside in the way of direct revenue but gives a lot of power in ensuring technical superiority versus other vendors:

  Mozilla and Google may use their support of WebRTC to attract additional users from Apple and Microsoft, increasing their market share

  Vidyo may use their assistance to WebRTC's technology stack in maintaining their first mover advantage in multipoint video conferencing capabilities

  Ericsson with their latest openWebRTC stack, rivaling Google's own WebRTC implementation

  Cisco who open sourced their H.264 video codec in an effort to sway the decision of WebRTC's mandatory video codec towards H.264

These vendors usually don't intend on banking from WebRTC directly and have indirect business models for WebRTC; at times the business model isn't easily apparent.

#### Tooling

Vendors in this position offer tools that make development of WebRTC-based services much easier. These vendors have varying business models focused around B2B, where the target market is other vendors who wish to deploy communication services.

These vendors can be split into several domains:

  API vendors

  Services vendors

  Infrastructure and SDK vendors

  Projects vendors

  Open source vendors

##### **WebRTC API Vendors**

These are vendors who provide either hosted or on-premise platforms that offer an abstraction on top of WebRTC as well as closing the infrastructure gaps of WebRTC. They may offer features such as connectivity to PSTN, mobile SDK, downloadable plugins or Flash support for non-WebRTC environments.

Such solutions are adopted by vendors who want to focus on their use case, mainly when that use case requires communication to be a feature that is stitched into their business processes. This has been coined CEBP (Communication Enabled Business Processes) and is a strong trend in the uptake of WebRTC.

There are many vendors in this domain, some who started as Telco API vendors and have added WebRTC to their arsenal of capabilities, and others who started as pure WebRTC API vendors.

A shortlist of these vendors includes but not limited to: 2600hz, AddLive, Apidaze, Forge, Kandy, OpenClove, TokBox, Respoke, SigntCall, Sinch, Tropo, Twilio and VoxImplant.

  | _Further Reading:_ 025 - bloggeek.me/ref/biz025/

  Who provides telco APIs

  API platforms adding video with WebRTC

  Choosing a WebRTC API Platform report

---|---

##### Services Vendors

There are pieces in WebRTC deployments that can be "outsourced" to others. These pieces are offered as service, where the SLA, global footprint and focus of the vendor on the specific service is the main offering.

In this domain, you can find XirSys as a notable NAT traversal providers, offering TURN server hosting as a service to those who don't want to deal with media relay in WebRTC and focus on their own service logic.

Another interesting set of vendors here are PubNub, Firebase and Pusher who offer low latency messaging infrastructure for developers. All have added WebRTC into their arsenal of tools; where they specialize in adding signaling to it.

The customers of the services vendors are usually those who are comfortable in developing directly on top of WebRTC but view the hosting of WebRTC components as less important to their core offering.

  | _Further Reading:_ 026 - bloggeek.me/ref/biz026/

  What's Your SaaS for WebRTC Signaling?

  An interview with XirSys CEO

  An interview with MNS CMO

---|---

##### Infrastructure and SDK Vendors

These vendors offer either equipment or licensed software that makes it easier for developers to build their solution. Here you will find a "breakdown" of features you'd expect to consume from APIs and services vendors in packaged format - building blocks that can be used to create higher level solutions.

The target market of these vendors is developers who are looking for more control of their solution. This includes large service providers and enterprises, and to some extent vendors who decided to manage their own data centers or manage their own cloud deployment and just need to bolt on a few features/capabilities.

Another interesting set of such solutions are PBX and soft switch vendors, who started offering WebRTC connectivity. As they offer an engine of sorts, it can provide a good starting point for many communication services. Since there are some solid open source offerings in that area, they are also very popular with developers.

You will find in this group of vendors offering gateways, media servers, NAT traversal server software, etc. Notable names include Dialogic, Eyeball Networks, GENBAND, Digium and FreeSWITCH.

  | _Further Reading:_ 027 - bloggeek.me/ref/biz027/

  An interview with Digium's Director of Strategic Programs

---|---

##### Projects Vendors

As with any vibrant community, there are those who offer their services to assist companies in building whatever it is they require. WebRTC include large and small software houses of this type - ones that take on development tasks related to WebRTC.

Some of these vendors offer a breadth of capabilities coming either from a broad outsourcing and system integration heritage, others are more focused into the VoIP and video processing space and the rest are starting off with WebRTC or can be considered as "heads for hire", usually focusing on projects to local vendors.

WebRTC being a new domain, there is a real need for such vendors as well as a rise in the number of vendors who are publishing their expertise in WebRTC and even investing in showcasing it in.

  | _Further Reading:_ 028 - bloggeek.me/ref/biz028/

  An interview with Oxagile's CTO

  Blacc Spot Media reference customer [Blacc Spot Media]

  An interview with Blacc Spot Media CEO

---|---

##### Open Source Projects

WebRTC is building around it a large and healthy set of open source projects. At the time of writing these lines (October 2014), there are over 2,800 github projects related to WebRTC. This number is growing consistently and they show a vibrant community.

These projects usually sprout from the following reasons:

1. A single person, student or other, looking into the technology and just introducing the results online for everyone to use and share. This is usually done to attract a potential employer

2. Someone with a pain point that can be solved with WebRTC. OpenVRI is a good example of this case - a hard of hearing person who decided to build a solution he will be happy to use on a daily basis

3. A vendor who believes in the open source movement and contributes components back to the community while building his own services and offerings

How much these projects will be used as the baseline of future projects and products outside of the scope of their original developer is an open question at this point in time. My assumption is that developers who are building WebRTC-based services end up "bumping" into them while Googling for things they need to do and decide in an ad-hoc basis if and how to adopt them. This practice needs to be handled with care, as the licenses attached to these open source packages may be limiting the business models in which the adopting vendor will be able to operate in the future.

  | _Further Reading:_ 029 - bloggeek.me/ref/biz029/

  Examples of WebRTC open source modules

  WebRTC Demo: How to Explain WebRTC to People

---|---

#### Vendors

Vendors are those who end up offering WebRTC-based communication services to the end users. Their market may be B2B or B2C, depending on who they serve.

It is hard to cluster these vendors together, as they cater different verticals and use cases. It is also where business models diverge greatly.

Vendors in this category may use a Tooling vendor to rely on, or just build everything from scratch on their own. Reasons for selecting different routes here depend on a large variety of parameters, unique to each case.

The use cases chapter will try to take a closer look as some of the markets to which these vendors belong to.

#### Repurpose

Repurposing WebRTC can be viewed as the gray market of WebRTC. There are active vendors in this space, where most of them aren't widely known - their use of WebRTC is such that is left behind curtains.

WebRTC, the open source project, as opposed to the specification, is a state of the art media engine. It is the result of GIPS' commercial offering and On2's proprietary video codec, coupled with Google's ongoing investment in its quality.

To put things in perspective, when GIPS got acquired by Google, many vendors who were GIPS' customers immediately started searching for alternatives, which were hard to find at that level of quality and capability. Among GIPS customers you could have found IBM, Google, Yahoo, WebEx, Nortel, AOL, Citrix, Avaya, Samsung and QQ.

When Google open sources WebRTC under a very permissive BSD license, they in effect provided anyone who needed a media engine free access to a high quality solution - only thing missing was an SLA.

Vendors have taken note, and some have pried bits and pieces of WebRTC that fits their needs and embedded them into their own products and services. This requires little publication of the fact, so most of these activities are left unknown in the market. The most known and notable such move was the one made by Vonage. Their story is outlined in the use cases chapter.

  | _Further Reading:_ 030 - bloggeek.me/ref/biz030/

  Changes in the media engine market landscape

  How Vonage repurposed WebRTC for their own needs

  An interview with Jan Linden of GIPS prior to its acquisition [Wirevolution]

---|---

#### 2nd Market

The 2nd Market of WebRTC is something quite rare but its existence is important to note.

WebRTC fuses between VoIP and the web. This brings two important traits together:

1. VoIP gains an open and modern delivery system - the web browser

2. The web gains P2P capabilities and real time communication

The web is based today on loosely coupled web sites and technologies that are mashed up together to build new solutions and services. The ProgrammableWeb is an important directory of web APIs used for mashup purposes. It documents APIs, mashups of them and stories around them.

At the moment, there are over 10,000 documented APIs and 7,000 mashups on the ProgrammableWeb:

**Figure 10: Growth pattern in web APIs**

This trend of mashup and open API publication is also something you see with WebRTC, and not only with the API vendors: many of the WebRTC services players are starting to offer APIs of their own for various purposes:

1. Integration into enterprise directory services

2. Integration with CRM/ERP systems of enterprises

3. Widgets and call buttons to place on websites

4. White labeling and branding via APIs

To some extent, this creates a 2nd market of companies who integrate with these services vendors and still see themselves as part of the WebRTC ecosystem.

The most distinct example of this is Intuitive Solutions, who are running a managed contact center service for customers. Intuitive Solutions in this case, have even publicized this initiative in a press release and see themselves as a WebRTC player to some extent.

**Figure 11: The WebRTC value chain and the 2 nd market**

Intuitive Solutions run their service on top of LiveOps, which provides contact center SaaS systems for its customers. LiveOps have built their own solution on top of Twilio, a WebRTC API vendor.

  | _Further Reading:_ 031 - bloggeek.me/ref/biz031/

  TNW Academy announcement [TheNextWeb]

  The new value chain that WebRTC enables [UC Strategies]

  WebRTC 2nd Market: The Story of Intuitive Solutions

---|---

## WebRTC Use Cases by Verticals

This chapter holds the main body of this research paper. It consists of various verticals and use cases of real vendors within those verticals who are using WebRTC in one way or another.

The purpose of it is for entrepreneurs and product managers to get acquainted with the market dynamics of WebRTC and to see how different vendors are tackling the technical and business issues associated with the introduction of WebRTC.

##### Things to Remember

  The vendors listed in this chapter were selected not due to their technical merit or the type of support they provide - these were not part of the analysis done. The vendors listed here were selected as examples of the different services and business models that vendors are offering in the WebRTC ecosystem.

  Many of the vendors in this section have been interviewed for BlogGeek.me in the past. You can find more about them here: <http://bloggeek.me/webrtc-interviews/>

### Tooling

Tooling vendors are at the heart of the WebRTC ecosystem. They are the enablers filling the gaps that the WebRTC specification doesn't solve - this essentially mean a lot of backend capabilities.

These vendors come in different shapes and sizes. I have selected 3 such vendors:

  **Digium** - the vendor behind the popular Asterisk SIP communication platform, who has added WebRTC to Asterisk's capabilities

  **GENBAND 's Kandy** - a Telco API vendor, enabling anyone to build a use case on top of their platform instead of directly on top of WebRTC

  **XirSys** - offering a NAT traversal service in SaaS form

#### Digium

Digium offers a popular and widely used open source communication framework called Asterisk. Founded in 1999, Digium have been in the VoIP arena a lot longer than WebRTC.

Asterisk added support for WebRTC, which enables anyone who need a PBX or other SIP server to be able to connect calls to it over WebRTC from a browser. This support is being used by multiple software vendors already.

Asterisk isn't alone in this domain. There are other such open source VoIP platforms that have added or are in the process of adding WebRTC support.

The advantages of adopting an existing VoIP platform that added WebRTC are:

  Easier integration with existing VoIP deployments. Main domains that are already using this approach are contact centers and unified communication solutions

  Rich framework and architecture, with an existing ecosystem of developers and outsourcing vendors

Recently, Digium have introduced a new WebRTC API Platform called Respoke.

##### Things to Remember

  This route is usually selected by "hard-core" VoIP developers, especially when connecting a legacy VoIP or PSTN system to the web

  These platforms tend to have open source licenses - some more permissive than others. Check the license to see that it fits your business needs

  This support of both WebRTC and legacy brings with it limitations to what can be achieved with WebRTC - things like video support, or Opus voice support comes to mind here

#### GENBAND's Kandy

GENBAND is a vendor specializing in carrier grade communication products.

In 2014, it launched a new Platform as a Service called Kandy, which delivers its set of capabilities via API and SDK to developers, enterprises and carriers.

Kandy offers the ability to create real time communication based services with little knowledge of WebRTC or communication related technologies. It does so by offering REST APIs, SDKs for Web and mobile and a cloud-based communication platform.

Kandy is targeting a variety of developer archetypes:

  Service Providers, who wish to deploy the solution within their own controlled environment and use it to build their own services, or white label it altogether

  Enterprises, where an SLA and the ability to customize and offer a solution on top of an API platform is necessary at times

  The long tail, where any developer can on board and start developing immediately with little friction

The things Kandy's team is most proud of is their ability to simplify the development effort required, taking out of the equation a lot of the challenges associated with developing WebRTC and communication related services for web and mobile.

##### Things to Remember

  Many vendors are currently competing in this space, each with his own differentiating business or technology factors

  Kandy provides an end-to-end Communication-as-a-Service solution

  This space is dynamic, with several players getting acquired and taken off the market. The selection of a vendor to work with is an important and non-trivial one

#### XirSys

XirSys offers a SaaS for WebRTC NAT Traversal. In many cases, developers don't wish to deal with the hassles of installing, setting up; integrating and maintaining STUN and TURN with their WebRTC service.

In such cases, they search for vendors who can provide this solution under an SLA.

The advantages of outsourcing this to an external vendor includes:

  Wider coverage around the globe

  Ability to focus on user experience of the solution being developed

  Flexible support for spikes in service use

  Predictability of costs and reduction in ongoing development and maintenance costs

A NAT Traversal SaaS vendor is also capable of providing additional insights to its users via reporting and analytics - areas where most developers will not invest until later into the service lifecycle.

##### Things to Remember

  SaaS can include other types of services. NAT traversal is the most obvious one, but signaling, media processing and recording are all areas where developers have indicated the need for assistance

  When building a service, SaaS solutions can greatly reduce time to market with the initial minimum viable product. In the longer run, it can simplify your work

### Video Conferencing

Video Conferencing is a market that exists for over a decade. Its focus over the years has always been Enterprise Video Conferencing, sold to multinational companies with large IT budgets.

In recent years, companies have moved to offer Cloud based video conferencing offerings, in an attempt to shift IT spending from CAPEX to OPEX and to start selling video services instead. WebRTC is now part of this trend and can be viewed as an accelerator of it.

Many of the initial WebRTC vendors tried to penetrate this market, with the main value being a reduction in the end cost to the customer due to their lower development and operating costs.

The vendors provided in this subchapter as example use cases were selected due to their business models and geographical variety:

  **Pexip** - Norwegian startup company focused on cloud enterprise video conferencing

  **Sqwiggle** - San Francisco based startup focused on collaboration between remote workers in the same team

  **Veeting Rooms** - Swiss startup putting its focus on data privacy

  | _Further Reading:_ 032 - bloggeek.me/ref/biz032/

  WebRTC isn't only about gateways [UC Strategies]

  Two ways for UC vendors to look at WebRTC [UC Strategies]

---|---

#### Pexip

Pexip can be viewed as the next generation of enterprise video conferencing solutions. It comes with the same world view of unified communication solutions of multiple video participants in a single meeting, but diverges from common practices in the following ways:

  Everything is software based - nothing required proprietary hardware

  The solution is fully virtualized - a new trend for enterprise video conferencing solutions that require real time response from the operating system

As with other cloud video conferencing platforms for the enterprise, Pexip markets its solution as connecting to any system - be it H.323, SIP or WebRTC - coming from any device.

Pexip is a Norwegian company, based out of the same talent pool that started off Tandberg - a video conferencing vendor that got acquired by Cisco a few years ago.

Unlike the other vendors in this section, Pexip does not offer a hosted service, but rather licenses its software to run on-premise in its customer's data centers.

##### Things to Remember

  Video conferencing in the enterprise is hard. A lot of issues there revolve around interoperability and transcoding. Only engineers with such domain expertise can build a solution for that market

  For Pexip, WebRTC is just another device connecting into their network - it isn't at the heart of their architecture

  | _Further Reading:_ 033 - bloggeek.me/ref/biz033/

  Overview of Pexip Infinity video MCU [NoJitter]

---|---

#### Sqwiggle

Sqwiggle is trying to solve the collaboration challenges of remote workers in the same team. It does so by redefining video conferencing in enterprises and making use of ambient video technologies.

Sqwiggle places the whole team in a single web page, where still images of the team members get updated several times a minute. This creates a type of presence that bridges the distance within the team.

At a click of a button, a video session can start between two peers in the team, without the need for the "called" peer to answer or decline the call. This ends up feeling just like raising your head from the computer to ask a colleague in the same room a question.

Interestingly, most of Sqwiggle's video calls are really short. This is the opposite of common enterprise use cases where video calls span 30-60 minutes on average (the length of a scheduled meeting in the calendar).

##### Things to Remember

  Video communications in the enterprise comes in different shapes and sizes. The fact that legacy vendors have focused on a specific use case doesn't mean other use cases don't exist

  Presence can be a lot more fluid than "online, offline, busy and away". Sqwiggle redefined it by making taking a picture of its users and making them available to the team

  Sqwiggle doesn't aim to connect to any existing video conferencing equipment. It lives as a standalone solution and works well in that context

#### Veeting Rooms

Veeting Rooms provides a web meeting service enabling multiple participants to attend a video conference.

While many provide similar capabilities, Veeting Rooms differentiates itself from the rest of the pack by putting emphasis on data privacy.

Everything in Veeting Rooms - from the data center used to hosting their service, to the third party SaaS providers for analytics - are located within Switzerland, where strict data privacy rules exist.

Veeting Rooms have built their system in a way that enables them to white label and even replicate the solution to another geography if necessary.

##### Things to Remember

  The Enterprise Video Conferencing market competed in the past decade mainly on port density, resolutions and video quality. With "good enough" solutions, it is becoming hard to differentiate

  Small startups like Veeting Rooms are finding gaps and needs in the market that are ignored by the incumbents and offer tailored solutions. Data privacy is such a gap for the competing cloud providers of video conferencing

  As with the case of Sqwiggle, Veeting Rooms refrains from addressing the existing video products, instead making use of WebRTC in the browser

### Telecommunications

Carriers have their own interest in WebRTC. This stems from the basic notion that WebRTC provides communication capabilities that can be either wielded by OTT vendors, competing on voice and SMS services, or by the carriers themselves.

The domain of carriers is larger than what can fit in such a paper, with multiple directions that can be taken and are taken today. In this section, several non-obvious approaches of carriers into WebRTC are described:

  **appear.in** - an ad-hoc video conferencing service based on WebRTC

  **Comcast** - video streaming to a set top box

  **Vonage** - broadband service provider in the US that is using WebRTC to "go mobile" and introduce video

  | _Further Reading:_ 034 - bloggeek.me/ref/biz034/

  What WebRTC means to telecoms [Alan Quayle]

  Network effects, Telcos and WebRTC [Baby is 60]

  What are Carriers Doing with WebRTC? Everything But IMS

  Comcast Getting it Right with WebRTC: Opts for Video Streaming over Video Chatting

---|---

#### appear.in

appear.in define themselves as a startup within the incubator environment of Telenor Digital. They offer a simple, ad-hoc, multipoint video conferencing service.

The service started as an interns' project. It gained traction and popularity, which caused Telenor Digital to invest more resources into it.

Today, appear.in offers a decent video conferencing service that can work with up to 8 participants, along with an iOS app.

##### Things to Remember

  There are similar services out there. This is the only one developed and managed by a Telecom vendor

  It is an experimental service for Telenor, as there is no business model apparent at the moment behind it

  Vendors (especially incumbents) need to tinker and play with WebRTC to understand its capabilities, and decide from there where it fits

  There is more to do with WebRTC in Telecom than simply make it an access point to the IMS network

  Small teams in large companies can develop great services if you let them

#### Comcast

Comcast is the largest cable provider in the US. Its XFINITY X1 Platform is used by many of its customers as their Pay TV platform.

Recently, Comcast announced its plans of adding video streaming capabilities which will work similar to how Chromecast does: it will enable their customers to live stream personal video content from their mobile devices to the television via the X1 set top box.

This capability is added by way of WebRTC.

On top of that, Comcast has invested in the Jitsi Videobridge, which provides multipoint video calling capabilities. The reasons and target service for this investment has not been made public.

##### Things to Remember

  While the obvious addition of WebRTC to a set top box would have been video calling, Comcast has taken the route of enabling better video streaming user experience with WebRTC

  There are many ways to use WebRTC besides enabling a peer to peer video call

  WebRTC use cases are not limited to the browser or even to a mobile device. The X1 platform is an embedded device that has WebRTC support to it

  Telecom Carriers are large companies with multiple services. There are many ways in which they can leverage WebRTC. Comcast seem to be doing it both as a video streaming capability on their X1 platform and as an unannounced multipoint video conferencing solution (based on their Jitsi Videobridge investment)

#### Vonage

Vonage is a voice communication provider that used WebRTC to build a mobile client and to add video calling.

Vonage has been operating since 2001, offering its ~2.3 million subscribers with unlimited voice calling to over 60 countries over its VoIP infrastructure.

Vonage was running predominantly on IP phones over wireline connections, and wanted to expand their offering in two new trajectories:

1. **Mobile** - introducing a BYOD mobile application that can run on Android and iOS devices, enabling Vonage customers to use their service anywhere

2. **Video** - add video calling capabilities on top of their extensive voice service

To do that, Vonage took the following steps:

  Looked at WebRTC as a pure open source technology stack

  Adopted and ported the WebRTC code base to run on Android and iOS

  Replaced the voice codecs used in WebRTC from G.711 and Opus to G.711, iLBC and iSAC - this removed the need to transcode media when calling between their existing wireline service to their new mobile application. It has since then added Opus support as well

  Used VP8 video codec that comes with WebRTC to offer video calling between their mobile applications

  Added SIP signaling on top of WebRTC in their native application, to support the same signaling of their existing wireline service

This approach enabled Vonage to meet their requirements with little change to their core infrastructure. Today, the Vonage application has been downloaded over 1 million times from the app stores.

##### Things to Remember

  Purists will not see this as a WebRTC initiative, as it treats WebRTC as any other generic media engine

  Such a development project was rather expensive at the time Vonage started (2012), but costs a lot less than it used to prior to WebRTC

  The fact that WebRTC can be plagiarized is one of its unique values

### Customer Service & Support

One of the areas where many see the value of WebRTC is customer service and support. The main example given is usually the ability of a customer to surf a website, click a call button on the website and get connected to an agent.

This being said, WebRTC has many different uses in the domain of customer service and support - some of which may prove to be a better fit for many enterprises.

Use cases in this section include:

  **Amazon Mayday** - Amazon's new video support service. While its use of WebRTC isn't confirmed, it may change the way contact centers are going to be structured

  **FreeCRM** -a CRM service that adopted WebRTC to enable calling contacts right from within the CRM service, without the need to pick up a phone and dial

  **Intuitive Solutions** - a Texas managed contact center company that changed the way they make decisions by using WebRTC

  **Vacasa Rentals** - a vacations provider using WebRTC internally to run their day to day operation

  | _Further Reading:_ 035 - bloggeek.me/ref/biz035/

  WebRTC disruption in the contact center [UC Strategies]

  Where Amazon Mayday's service is headed [Disruptive Wireless]

  Challenges of WebRTC and customer service [WebRTC World]

  What the Amazon Fire Phone Predictable Failure can Teach us About WebRTC?

  Why Invest in WebRTC When Everyone Goes Self Service? [UC Strategies]

---|---

#### Amazon Mayday

Amazon Mayday is a service offered by Amazon for free to its Kindle Fire tablet and Fire Phone customers. With it, a customer can press a Mayday button on his device and get connected with a service agent within 10 seconds.

A lot has been written about this service on the internet. The most interesting aspects of this service are:

  It is the first time Amazon provides live agent support. Up until now they had only email support. They took the extreme of offering live video support instead of voice only

  Their target is having all calls answered within 15 seconds, something unheard of it in today's contact centers. They achieved an average wait time of less than 10 seconds

  The solution is targeted at their tablet and smartphone buyers only, as a differentiating point from other mobile device vendors

  The service supports one way video, two way voice, the ability of the agent to take control of the tablet remotely and the ability of the user to share everything he is doing on the tablet in real-time

While the technical details were never provided, it is safe to assume that such a solution is based on WebRTC: Amazon's Kindle Fire tablets and Fire Phones are based on the Android operating system. WebRTC is developed by Google with support for Android, so having something readily available that can be used and integrated without paying for it seems like a good bet.

##### Things to Remember

  The deep integration done by Amazon with the ability to maintain a live call while using the tablet and sharing the screen across applications isn't trivial. It was made possible by the fact that Amazon controls the chipset, operating system and services on their tablets

  This move may have a large impact on contact centers, customer support and mobile device vendors alike. Since Amazon's announcements, many companies (startups and established) have been introducing their own angle to the Amazon Mayday button

#### FreeCRM

FreeCRM offers a CRM system in a freemium model. One of its paid features is the ability to call contacts from the CRM directly.

The contacts don't need to be using WebRTC in any way - they receive their call on the regular telephony service (PSTN).

In the past, FreeCRM has been integrated with both Skype and Vonage, but recently they have added the ability to use WebRTC. This provides a transparent experience to the user, who does not need to have an account at any other service. It also makes it easy to track the calls, their progress and even content and have that automatically reflected in the CRM system.

FreeCRM have built their own solution based on the Asterisk communication framework, connecting calls to the PSTN via a SIP gateway.

The service offers a voice only solution and is available on supporting browsers, which is a legitimate approach for a CRM solution targeted at SMBs and enterprises.

##### Things to Remember

  Seamless integration of calling capabilities into the contact center makes it easier to handle and provides a single vendor solution

  In this domain, PSTN connectivity is important

  Such a solution can be achieved by self-development or by utilizing API vendors

#### Intuitive Solutions

Intuitive Solutions is a managed contact center service located in Texas, specializing in the pizza restaurant business.

Intuitive Solutions was looking to grow, but had several challenges:

1. Office space

2. VoIP software client for agents that was hard to manage and maintain, especially with remote workforce

3. 4 different vendors handling their contact center

Intuitive Solutions searched for a single vendor to offer all of their IT needs, be it CRM or contact center related. They found such a third party platform that provided them CRM capabilities along with the ability to receive incoming calls using WebRTC from within the browser.

This solution offered Intuitive Solutions the following benefits:

  Hassle free deployment and management of VoIP clients, as they are now a part of the Chrome browser

  Ability for contact center agents to work from home or a coffee shop, freeing them from the brick and mortar office space, and allowing more flexibility in work hours

  Better decision making due to a clear view of their day to day operations, as the new vendor had integrated CRM and telephony reports

##### Things to Remember

  Intuitive Solutions isn't a technology provider, and yet it sees itself as a company directly benefiting from WebRTC

  Fusing VoIP with the web enables tighter integration across software applications, bringing with it better visibility and insights for the business

  As companies mature and try to grow out of their niche, with CRM vendors win the contact center market, or will VoIP PBX and contact center vendors win over the CRM market?

#### Vacasa Rentals

Vacasa Rentals is a US based company providing a vacation homes rental service.

They handle around 500 homes spread across 6 different states in the US. They do this by operating solely on the cloud using SaaS services. Besides dealing with physical laptops and smartphones, all the rest runs off virtual services - and that includes their telephony system as well.

Vacasa Rentals debated as to the approach to use between VoIP and softphones to WebRTC, and ended up using WebRTC. This provided them more flexibility in how calls are routed to the relevant Vacasa Rentals agents, who at the end of the day received the calls via WebRTC on their browser.

Vacasa Rentals planned on doing the whole development work on their own, but ended up using Plivo, one of the WebRTC API Platform vendors.

#### Things to Remember

  This is a contact distribution solution, where incoming calls from PSTN get routed via WebRTC to the relevant agent

  While not a VoIP company or a contact center vendor, such use cases exist out there - vendors who do their business mainly via the phone and need intelligent routing. They may end up developing it on their own, using a third party WebRTC API Platform vendor, using a contact center solution or using traditional VoIP

### Expert Marketplace

There is a market forming about expert services - people with knowledge in a specific domain who wish to share that information. Think of this market as the personal gym trainer, only online - and yes, there is more than a single vendor who offers this kind of a personal gym trainer service online via WebRTC.

But the expert marketplace is larger than your typical gym, with experts from a large variety of domain selling their time online. If you are a domain expert, then why not reach out to customers via the web? While this can be achieved via Skype on the technical level, these platforms offer the means to discover experts, understand their skills, see ratings and comments of their customers, have the ability to interact with them, schedule the session online and pay for the service - all from within the same website/webpage/service, with a single identity and without the hassle of installing any software - that has real value.

It isn't surprising then that there are WebRTC vendors in this market already, and two of them are:

  **LiveNinja** - offering their solution on top of TokBox API platform

  **popexpert** - who developed a homegrown solution of their own

Apart from the two vendors detailed here, there are other vendors who offer marketplaces for smaller niches.

  | _Further Reading:_ 036 - bloggeek.me/ref/biz036/

  Review of the experts market and its opportunities

---|---

#### LiveNinja

LiveNinja is one of the vendors vying into the expert marketplace.

It started off running on top of TokBox platform in its Flash days and shifting with TokBox into WebRTC.

LiveNinja offers a platform for experts of any kind to host their service online - from the creation of a profile page, to comments and ranking capabilities, scheduling and payment. All this is wrapped under a discovery engine enabling users to find a suitable expert for their need.

The business model around expert support is based on revenue sharing, where the user scheduling a session with an expert pays for the session and LiveNinja takes a percentage of that amount as processing fees.

As the platform of LiveNinja evolved, so did their solutions and focus. Today, LiveNinja offers a webinars platform, based on one-time fees for the session; along with OEM'ing the platform for integration into other solutions.

A new and interesting service from LiveNinja called Katana offers a video contact center that can be embedded into existing websites.

##### Things to Remember

  While expert advice over the internet has existed prior to WebRTC, WebRTC offers a simpler user experience where the whole business process is handled by a single vendor, under a single roof, from a single website

  What enables LiveNinja to move fast and offer new capabilities such as webinars and events is their reliance on an API vendor, who provides these capabilities as part of the service

  For its Katana service offering, LiveNinja have opted for building its infrastructure on its own, due to limitations of the API vendor it used in the features necessary in Katana

#### Popexpert

popexpert is similar to LiveNinja in many ways. It too offers a platform for experts to build their profile pages, schedule and sell their time online - with the same type of business model - revenue sharing.

Unlike LiveNinja, popexpert have taken the route of developing the solution from the ground up on their own - including all of the WebRTC related parts. While popexpert did start out by using an API vendor, they switched along the way to their own implementation - this gave them an independence from the feature set (and bugs) of an API vendor.

##### Things to Remember

  An expert marketplace solution is about marketing and service. To that end, the ability to customize the experience end to end is important. As with LiveNinja, a lot of the attention of popexpert goes to the user experience domain

  In the same industry, two different vendors choose different directions with WebRTC - some will go for tooling vendors for assistance while another would prefer independence and self-development. The fact that getting started with WebRTC is simple, these two options for every use case can almost always be found

### Telehealth

Telehealth is an interesting market segment when it comes to WebRTC. The challenge with healthcare services is dealing with regulation and the liabilities involved in the interactions created. US based vendors, for example, need to adhere to HIPAA compliance, which stands for Health Insurance Portability and Accountability Act. HIPAA includes directives around privacy of patients amongst other issues - areas requiring special attention and care from the vendors offering Telehealth solutions.

WebRTC is uniquely positioned as a very suitable technology. The reasons for that include:

  WebRTC is secured and private by default, whereas other systems can optionally be made secure

  WebRTC is suitable for easy incorporation into business processes - and Telehealth is all about business processes (from a regulatory point of view)

  Development of Telehealth requires a lot of knowledge and experience of healthcare - something that is hard to come by in the VoIP domain, so having something like WebRTC that makes it easy to develop VoIP use cases, makes it possible to develop Telehealth services

The vendors discussed in this section provide different Telehealth solutions that are built differently and have very different business processes:

  **Clrais Healthcare** - connecting seniors to their loved ones

  **Regroup Therapy** - provides single and group therapy sessions remotely

  **TruClinic** - provides solutions to everyone in the healthcare industry

  | _Further Reading:_ 037 - bloggeek.me/ref/biz037/

  How Regroup is bringing the shrink's couch online [VentureBeat]

---|---

#### Claris Healthcare

Clearis Healthcare develops and sells the Claris Companion, an Android-based tablet for seniors.

Their role is to enable seniors to increase their connectivity with their loved ones. This is achieved by offering a specialized tablet device with a user interface and applications capable of supporting specific activities and needs of seniors.

The device can communicate with other family members by using WebRTC as the technology of choice, making it suitable for smartphones, tablets and browser communications.

##### Things to Remember

  While not a healthcare service per se, the Claris Companion is targeted at an audience with specific needs focused around healthcare

  WebRTC and the rise of tablets enabled Claris Healthcare to offer this type of service while focusing on the user experience

  Claris Healthcare are combining a business model of selling a device with a monthly subscription fee

#### Regroup Therapy

Regroup Therapy enables the creation of personal therapy sessions or group therapy sessions.

While the solution may seem similar to the services provided by LiveNinja or popexpert, it is actually quite different; the reason being the need to handle the healthcare regulation.

Therapists who wish to provide remote sessions to patients, can leverage Regroup Therapy and open up their account online. Regroup Therapy takes care of onboarding these therapists and checking their credentials and ability to treat patients.

Those looking for therapy, can find online a therapist who fits their needs; or even visit a therapist in his office and later on shift to doing online sessions from the comfort of his home.

Regroup Therapy takes its share of the cost of any given session.

##### Things to Remember

  Developing such a solution require as much knowledge and experience (or even more) in group therapy as it does in communication technologies - this knowledge spans down from legal aspects, through bureaucratic/political aspects and up to behavioral aspects

  Healthcare comes in different shapes and sizes. Group therapy is one such domain. Many other care related services can be provided by utilizing WebRTC

#### TruClinic

TruClinic provides a healthcare portal, where patients can virtually visit doctors online.

In the case of TruClinic, WebRTC plays the role of providing video calling stitched into specific business processes - ones that need to be secure and private due to the regulations surrounding healthcare services.

Unlike other verticals, where friction of using the service needs to be eliminated, healthcare requires a certain degree of friction - the ability to register a patient, record his history and health status, and be able to authenticate him properly.

##### Things to Remember

  In the domain of healthcare, a lot of attention is provided to regulatory standards. WebRTC reduces barriers of entry to video conferencing domain, which in turn enables savvy healthcare players to enter this market and offer their expertise in the administrative components of the system

### Gaming

One of the most untapped markets when it comes to WebRTC is gaming. There is a lot of chatter about the potential uses of WebRTC in this space, but very little action.

This is why this section covers more demos than actual games. It is here to provide an overview of what capabilities of WebRTC are currently being researched and played around with by developers, and where that may lead us looking forward.

The games and concepts in this section are:

  **BananaBread** - a demo of a first person shooter game using WebRTC's data channel to achieve low latency networking

  **CubeSlam** - Google's game concept, showing what can be achieved with WebRTC in a 3D game environment

  **Jocly** - online multiplayer board games, with a touch of WebRTC

  **Snake** - a simple demo using the web camera via WebRTC to... control the snake

It is interesting to note that the traditional VoIP people are more passionate about WebRTC in gaming than the gaming vendors at this point.

  | _Further Reading:_ 038 - bloggeek.me/ref/biz038/

  BananaBread game project page [Mozilla]

  The technology behind CubeSlam [CubeSlam]

  Jocly's use of WebRTC for immersive gaming [Jocly]

  Game of Snake that uses WebRTC [Nicolas Beauvais]

---|---

#### BananaBread

BananaBread is a traditional 3D first person shooter game ported to run purely on HTML5. This was done using Java Script and WebGL, where most of the initial code got automatic translation from C++.

WebRTC was introduced in 2013 to BananaBread. The data channel was integrated into BananaBread offering low latency network support for the exchange of information between gamers in a multi-player gaming session.

For multiplayer games, where low latency is important to provide better feedback to the gamers, the ability to offer P2P connections directly between the gamers can reduce latencies and also the load on the game server. But it hasn't been tested to see how much can this approach scale to larger groups of players, where multiple data sessions need to be opened by each browser to the rest of the players.

#### CubeSlam

CubeSlam is Google's attempt at showcasing two capabilities:

1. The ability of HTML5 to run games, showing off all of its capabilities

2. The usefulness of WebRTC for games

The game itself is the classic pong game, skinned in 3D, colors and the added video chat.

The interaction and data passed between the two players of the game is sent via WebRTC data channel. Added to the game is a video chat session that enables both players to see each other in real time. The video display is tilted with the board game as necessary using WebGL.

The video component of this game isn't used for the game itself, but rather as a way to get the players closer to each other and enhance the experience of the game.

#### Jocly

Jocly Games is a bootstrap company from France, who are focused at delivering strategy and board games to their community of players.

The games are all HTML5 games, and recently, WebRTC was added to the experience - offering the ability of people to have a more immersive experience, where they see each other during the game itself.

While not all the gamers are using the video chat option that WebRTC offers there, it does seem to be gaining traction.

At the moment, Jocly Games have no monetization going around, but this may change as they grow in audience. The most obvious choice here would be ads.

#### Snake

The game of snake can be considered as an HTML5 demo written by Nicolas Beauvais for no other reason than to show it is possible to do.

It is the classing Snake game, where a small snake needs to be navigated to eat eggs and grow in the process. The game ends when the Stake steps on his own body.

The only difference here besides running it on a web browser as opposed to a monochrome monitor or an old Nokia feature-phone is the ability to use the web camera to control the movements of the Snake. This is achieved by using a Java Script library called headtrackr which enables capturing the video with WebRTC GetUserMedia and then process the images of the video to track the head.

While the end result is clunky and hard to use for this specific game, it might have implications on user inputs in other WebRTC games - especially considering the capabilities introduced by Microsoft's Kinect camera and Leap Motion.

### Social Networking and Consumer VoIP

I have decided to group consumer VoIP solutions (known also as communication OTT) with social networks as both serve a similar purpose: enable people to communicate.

In this domain, vendors tend to provide free services with business models based on ads, premium features or data monetization - sometimes, they have no apparent business model besides the need to grow to a certain size where they either get acquired or a new business model presents itself.

I have selected two different vendors here, each focusing on a different target market:

  **MaxiAmigos** - a dating/social media service for Brazilians

  **Solaborate** - a business focused social platform

It is interesting to note, that most social network solutions prefer the route of direct integration with WebRTC over the use of a 3rd party API vendor.

  | _Further Reading:_ 039 - bloggeek.me/ref/biz039/

  Social networks versus VoIP vendors

  Comparing the size and interactions of Skype vs. Facebook

  Monetization in the OTT VoIP world

---|---

#### MaxiAmigos

MaxiAmigos was the first dating/social network to embrace WebRTC. They offer an experience similar to Facebook, but operate locally in Brazil, and in it, mostly in Sao Paulo.

MaxiAmigos offers an offline messaging service, where voice and video communication comes secondary. They first relied on a Flash based service, but once that service switched to a paid model, they opted for WebRTC. WebRTC in this sense offered them more control and freedom over the solution.

MaxiAmigos started off integrating voice into the service, and recently they have added video calling as well.

In terms of monetization, MaxiAmigos started off with an ads strategy and is planning to move towards a different freemium model.

##### Things to Remember

  While not a distinct dating service, this does show the potential. There are a couple of dating services who are planning to introduce WebRTC in the near future

  Switching from Flash to WebRTC offered MaxiAmigos the freedom they needed and at the same time improved the quality and experience of the service they provided to their users

#### Solaborate

Solaborate define themselves as the missing link between Facebook, LinkedIn and Yammer dedicated to technology professionals. This positions them as a niche social network that caters the need of a specific target audience.

Solaborate uses WebRTC to enable voice and video calling - both 1:1 calls as well as multipoint conference calls.

One of the interesting facts about Solaborate is that they opted to run in Microsoft Azure cloud instead of other cloud providers. While this is different than how other vendors have approached the backend challenge, it seems to work well for Solaborate.

##### Things to Remember

  WebRTC enables embedding voice and video communication experiences into other web services. In the case of Solaborate it enables enhancing social networks

  There are different backend technologies that can work well with WebRTC. Pick the one you are most comfortable with in terms of the engineers you have

### Streaming and Content Delivery

One of the most interesting components in WebRTC is the data channel, which enables sending arbitrary data directly between browsers. As such, it provides capabilities that weren't possible before.

There are several strong capabilities the data channel brings to the table - capabilities that are already being exploited by vendors:

1. Ability to reduce load on a central server - when multiple consumers are getting at the same piece of data, they can assist each other instead of hammering the same central server with the same requests

2. Ability to communicate securely - as anything else in WebRTC, the data channel itself is encrypted. This enables sending data securely from the clients

The two basic building blocks above can be used in various ways to reach different sets of results each time - like Lego pieces. In this section, I'll introduce three different vendors, who are using the data channel's capabilities to achieve different results:

  **Peer5** - a vendor specializing in peer assisted data delivery, focused on CDN and file transfer

  **PeerMesh** - a P2P GIS solution

  **Swarmify** - providing CDN augmentation via the data channel

#### Peer5

Peer5 is an Israeli startup that has focused from the start on the data channel. The entrepreneurs behind Peer5 came with web experience and knowledge and no background in VoIP.

What they found in WebRTC was the ability to connect browsers directly, and they have built on top of that basic function the ability for multiple browsers to cooperate directly amongst themselves when trying to access similar content.

That capability can be used to reduce the load from video streaming servers, which is what Peer5 does; and it can be used to share files online, which is what Sharefest, another service by Peer5 does.

The advantages of using such peer assisted technologies are:

  Reduce load on the servers who hold the original content

  Reduce bandwidth requirements from the server farm

  The more people try to access the same content at the same time the better the system is capable of reducing the load on it

#### PeerMesh

PeerMesh is a peer-to-peer GIS technology.

GIS, which stands for Geographic Information Systems, is designed to handle geographical data (aka Maps). One of the challenges with GIS is the need to send large amounts of data from the server towards the clients of a GIS service.

PeerMesh comes to solve that by using WebRTC's data channel similar to how Peer5 does, but their main focus is GIS.

The service has been created by a developer and a UX designer living in Turkey and working for a vendor in the defense industry. While they have no solid commercial plans for the service at the moment, it shows how WebRTC can be used to solve challenges in a large range of domains.

##### Things to Remember

  A relatively small team can make use of WebRTC to solve a challenging problem

  WebRTC isn't limited to voice and video communications. There are many areas in which it can be suitable via its data channel

  The use of WebRTC is worldwide phenomena. Developers the world over are tinkering with it at any given time

#### Swarmify

Swarmify is a service that provides similar capabilities to those offered by Peer5: it enables multiple web browsers accessing the same content to share pieces of the content directly between each other, similar to how BitTorrent works.

What makes Swarmify interesting is the simplicity they provide: by adding a piece of JavaScript code they provide to web pages, and from that moment and on, the website "takes care of it" by letting page viewers share content pieces of the site automatically.

On the business model front, Swarmify offers just as simple tiered price plan, with customized plans for large enterprises. The idea behind it is the reduction of the CDN costs paid by websites.

The advantages of using this scheme:

  This can be used (and should be used) in parallel to running a CDN

  When possible, Swarmify will kick in and just offload the work from the CDN. This saves on cost but may also reduce latency

  Even with Chrome and Firefox alone supporting WebRTC, this kind of a service brings great value

### Other

There are many more stories and use cases that didn't make it to this research paper. Some because they bear similarities to other stories here, some because of breadth and time while others still because of my knowledge on them.

In this section, I want to introduce a few more use cases - ones that didn't fit elsewhere. These are:

  **fresh tilled soil** - a web design house from Massachusetts

  **OpenVRI** - a single person's pet project for the visually impaired

  **WebRTC School** - that offers certification programs for WebRTC

#### fresh tilled soil

fresh tilled soil is a UX design house. They deal with web and mobile apps - designing and implementing them for customers.

One might as what does such a company has to do with interactive video calling capabilities, but the answer is quite obvious - WebRTC is an HTML5 capability, so using it and harnessing it for customer projects is something that web companies will probably start doing in the near future.

fresh tilled soil started dabbling into WebRTC without a specific customer. In their case, it meant being able to understand the technology and showcase it to potential future customers that wanted something special for their next web project.

They ended up releasing their own WebRTC widget to the world as part of this pet project.

##### Things to Remember

  fresh tilled soil is at the forefront of such development outfits. Others will follow if customer demand for such capabilities start piling up

  The challenge for such vendors will be in the deployment of such a service, which requires a bit more handholding and maintenance than the usual web project. They will probably end up leaning towards one of the tooling vendors that offer SaaS models to deliver projects to their customers

#### OpenVRI

VRI stands for Video Remote Interpreting. VRI enables two people who are located in the same room to communicate when they don't share the same language or when one of them is hard of hearing - this is achieved by opening a video call to another person, who knows languages of both of the people or knows sign language and can interpret a deaf person.

VRI solutions are usually expensive, as they are provided by the same devices and services of enterprise video conferencing solutions.

OpenVRI is the result of a single person, hard of hearing himself, who decided to offer a similar solution based on WeRTC - and make it freely available to anyone - both as a service and in source code form.

OpenVRI is different in many aspects from both other VRI solutions as well as WebRTC video calling solutions:

  It has been built by a single person, hard of hearing himself - this isn't an easy feat, especially considering the fact that it includes a voice channel

  It is free in every sense of the word. The service is hosted online and is accessible and usable freely, while the source code of the service can be forked and modified via github

  It has been developed for the personal use of the developer - he needed such a service, so he just created it

  The service is based around the concept of ad-hoc meetings. It generates a hashed, one-time ink that can be emailed to the relevant parties that need to be on the same session

  There is a text chat window for each participant, as opposed to a single timeline for all participants. This makes more sense to this type of a service, where people would like to see the text as soon as it is typed, and not necessarily at its entirety - at times, this is the main channel of conversation

  The developer of OpenVRI has since then joined a VRI company, where he continues to develop WebRTC based solution for the hard of hearing in an enterprise scale

#### WebRTC School

WebRTC School isn't a WebRTC vendor in the "classic" sense. It doesn't develop anything that is WebRTC-based, but rather provides training services around WebRTC.

WebRTC School is the work of Vocale, the vendor who also runs the SIP School. They have decided to tackle WebRTC and provide much needed training and certification programs.

The WebRTC School provides two separate courses, one targeted at developers and the other at IT people who need to integrate and maintain WebRTC services.

WebRTC School holds a supportive role in the ecosystem. There is room for more vendors and services to take similar roles and provide services not directly related to WebRTC, but ones that assist vendors in reaching their goals.

### The Missing Verticals

The list of use cases and verticals is by no means exhaustive. There are many more verticals that weren't covered here. Some of them traditional, such as telecom vendors, who provide SBC, gateways and other equipment to carriers and enterprises; and others, are markets of their own, such as education, banking, etc.

The use cases were selected because each tells a story - usually different than the ones that existed prior to WebRTC.

The ecosystem of WebRTC today covers around 500 vendors and services, many with no clear business model. In the coming years, the ecosystem will go through transition where some vendors will disappear, new ones will appear, others will grow and others still will merge and consolidate.

In some ways, WebRTC has been relegated into the background already, with services using it without announcing that fact at all. This shift indicates a more focused view on delivering the use case than on the technology.

## Recommendations

This chapter can be seen as a shortlist of recommendations of the various insights found throughout this research paper. They are general guidelines to those who wish to build services that use WebRTC.

**1** | **Start from a business case**

  Identify a challenge or a problem you wish to tackle, preferably with a pain-point applicable to a specific market niche

  Understand who will be willing to pay for what to solve this problem

---|---

**2** | **Research the competition**

  There are many WebRTC vendors out there providing solutions. Make sure you know who provides similar capabilities to what you plan today

  Google to find who they are, check on WebRTC blogs and news outlets to see who is out there

  Play a bit with WebRTC services online - see how the interactions feel like, what have people done with it

**3** | **Validate that WebRTC can cover your needs**

  Make sure it is available on the web browsers that your target audience uses

  Decide what your fallback strategy to browsers that don't support WebRTC is (options are: none, Flash, plugin)

  Don't forget to decide on how you wish your service to run on mobile devices: which ones, in an app or on the web, etc.

**4** | **Analyze the ability to use existing tooling solutions**

  Are you comfortable with outsourcing the work for external vendors that specialize in it?

  Can you use an API vendor to deal with the whole WebRTC part?

  Should you self-host everything or use PaaS offerings for things like NAT traversal or signaling?

  Are there open source modules available that you can integrate into your solution?

**5** | **Select technologies based on existing skillsets**

  What kind of backend do you need for your service?

  Which frontend capabilities are require?

  Do you have the resources in your company to handle this?

  Be sure to have a web developer on board

  Depending on the use case, you might want to consider having a veteran VoIP engineer or architect on board

## Appendix A: Online Resources

This appendix provides some links to other online resources out there, where the main focus isn't a technical one. If you are looking for thought leadership, business insights or market related information about WebRTC, then this can serve as an initial reference list.

### Blogs

There are many blogs who are now covering WebRTC; some of them are large news outlets while others bring deep thinking as well as user stories.

Below is a hand-picked list of such blogs. You can consider them mandatory reading list when it comes to understanding WebRTC.

  | _Further Reading:_ 040 - bloggeek.me/ref/biz040/

  Direct links to the blogs outlined here

---|---

#### BlogGeek.me

My very own blog, where I write a lot about WebRTC and try also to give room from experts by way of guest posts.

#### WebRTC Weekly

A weekly newsletter providing roundup of posts and articles from around the web about WebRTC. Curated by Chris Koehncke and me.

#### WebRTC Glossary

A glossary site for all terms related to WebRTC.

#### webrtcHacks

This is a blog site operated by Chad Hart, Reid Stidolph, Victor Pascual Ávila and Tsahi Levent-Levi. While dealing more with the technical aspects of WebRTC, it does offer business insights as well as providing an events directory for WebRTC.

#### Chris Kranky

Chris Koehncke's personal blog is a great source of information about WebRTC. He is opinionated, to the point and blunt. He also writes with a unique voice that is enjoyable to read every time.

#### Alan Quayle

Alan Quayle, an independent consultant in the telecommunication space. His focus around Telco APIs and enablers to these have brought him to look closely at WebRTC as well.

#### Disruptive Analysis

Disruptive Analysis is Dean Bubley's blog. He is a consultant in the telecommunication space that is looking at WebRTC as well.

He has his own research paper on WebRTC.

#### WebRTC World

WebRTC World is a dedicated portal for WebRTC created and maintained by TMCnet. It is the place to go for up to date information about vendors and their plans and announcements around WebRTC.

### Communities

There are several online communities where conversations around WebRTC happen. The ones here are those that I find the most informative and engaging.

  | _Further Reading:_ 041 - bloggeek.me/ref/biz041/

  Direct links to the communities outlined here

---|---

#### WebRTC on Google+

Google+ has two distinct groups for WebRTC. There is no difference in terms of the type of content between them. People in this group are very responsive to questions asked.

#### WebRTC Forum on Facebook

There is a lively forum around WebRTC that has formed in Facebook.

The main news items related to WebRTC are raised and discussed within this group, which has just passed 300 members.

#### Following WebRTC on Quora

Quora has a WebRTC tag, where many questions and answers can be found.

It can be a good place to ask your own business related questions.

#### Meetup Events

At the time of writing, there were 18 different WebRTC related meetup groups around the world.

These are localized groups that conduct local events about WebRTC. The target audience as well as the content of each meeting vary widely, but if there is a meetup located close by to where you live, join it to gauge the local community that is hacking its way around WebRTC.

## Appendix B: Choosing a WebRTC API Platform report

If you are interested in developing using WebRTC then you might consider my other report: Choosing a WebRTC API Platform

This report is intended in assisting you in making an informed decision on how to develop your next WebRTC-based use case. With it you will be making a more educated decision about which WebRTC API platform to use at the end of the day.

Download the report's introduction to learn more.

Spanning 131 pages, this paper covers in depth what WebRTC is, the challenges of using WebRTC, the different ways developers tackle WebRTC, and the vendor selection process that needs to be taken when choosing a WebRTC API Platform.

The report also details information about 16 different WebRTC API Platforms, to help you get started faster in your selection process.

**Who is this report for?**

This report is useful if you are:

■ An entrepreneur, seeking to start a real-time communication related initiative

■ A product manager, trying to understand the options in front of you

■ A developer, needing to decide which route to take with WebRTC

**Key questions addressed**

The research paper addresses the following key questions:

■ What is WebRTC?

■ What are the challenges in developing with WebRTC?

■ What are the available options to WebRTC development?

■ What are the KPIs when selecting an API platform for WebRTC?

■ What API platforms are there and how do they fit your needs?

## Appendix C: Finding out More

Other than this report, the following services are available:

#### BlogGeek.Me Blog

My blog is the place where the bulk of my writing exists. It is available freely and can be subscribed via both RSS and email. See http://bloggeek.me

#### WebRTCweekly Weekly Newsletter

The WebRTCweekly is a weekly newsletter. It lists articles from around the web about WebRTC from the past week. This service is offered freely and is curated by me and Chris Koehncke. See <http://webrtcweekly.com/>

#### BlogGeek.Me Monthly Newsletter

I am publishing a short monthly newsletter. It includes an answer to a question I was asked during the month, statistics out of the research on WebRTC that I am doing, an interesting project and a few other tidbits. See <http://bloggeek.me/newsletters/>

#### Reports

This is my second report about WebRTC. To find out about other paid reports I have written, see <http://bloggeek.me/reports/>

#### Consulting

I provide consulting services to vendors, especially around VoIP, video conferencing and WebRTC. See <http://bloggeek.me/consulting/>

## Appendix D: About Kandy

Kandy is GENBAND's Real Time Communications Platform as a Service (PaaS). Kandy enables service providers, integrators, partners and developers to enrich their applications and services with real time contextual communications. By providing developer-friendly access to the entire suite of GENBAND real-time communication toolbox in the cloud. Kandy allows anyone from IT to business owners to developers to embed video, voice, text, presence and collaboration into existing and new Web and Mobile applications in an aggressive time to market and within a cost effective subscription business model.

Real Time Communications enables businesses to interact with their customers, and employees to interact with one another, by seamlessly integrating live and immediate communication, improving efficiency and user satisfaction.

Kandy offers developers a sandbox and community, app showcase and innovative QuickStarts, APIs and SDKs for Web and mobile.

Kandy is available at kandy.io. Come build with Kandy today.

#### About GENBAND

GENBAND is a global leader in smart networking solutions for service providers and enterprises in more than 80 countries. From the Core to the Edge to the Experience™, the company's technology seamlessly evolves IP networks to new levels in scalability, security, profitability and efficiency. GENBAND's market-leading technology facilitates multimedia voice, data and video sessions and "anywhere" and "any device" services that scale on public and private networks. GENBAND is headquartered in Frisco, Texas, and has R&D, sales and support resources in more than 50 countries.

## Appendix E: Kandy Usage Scenarios

With Kandy you can quickly integrate communications into your existing applications.

**Concierge** - provide a premium service to your customers with the ability to video chat, share screens, recommend products, and more. See <http://concierge.kandy.io/>

**Collaboration** \- improve the efficiency of your communications by providing real time sharing of documents, images, videos, and more. See <http://collaboration.kandy.io/>

**Business Assistant -** Keep work and home life separate with your own business number you can use for voice, texting, and voicemail. See <http://ureach.com/006o/templates/reg.htm>

 While the WebRTC open source project may not offer a nicely packaged mobile SDK, the code itself is almost fully ready for both Android and iOS use already, with noticeable improvements with each new release.
 The Opera browser for desktop and Android also has WebRTC support
3 Some browsers offer additional optional voice codecs as part of their WebRTC implementation

4 All browsers supporting WebRTC today use VP8. Firefox is in the process of adding H.264 support. Microsoft announced support for only H.264 at this point

 IMS stands for IP Multimedia Subsystem and is the standardized solution for carriers. Its VoIP protocol of choice is SIP and you can find it in VoLTE, RCS and other IMS related specifications.
 A mashup is a web page or web application that uses content/functionality from multiple sources across the web. When one web service offers open APIs, other services can consume that API (as well as other APIs) to generate a new service offering
