This page is relevant to those who are WebRTC Premium Subscribers. It holds a bit of explanation of the field designation and values.


The upper limit on the number of employees the vendor has. This should be considered a rough estimate, providing an indication to the size of the vendor.

Vendor type

The position of this vendor within the WebRTC ecosystem. The available options:

  • core – vendor is core to WebRTC progress and basic implementation
  • tooling – vendor offers tools for other developers to build their solutions
  • vendor – vendor offers a service or a finished product that can be deployed
  • 2nd market – vendor uses another vendor who has a running service to offer his own service (and still sees himself as a WebRTC vendor/user)
  • repurpose – vendor repurposes the WebRTC codebase for something different
  • supportive – vendor has a supportive role within the ecosystem


The classification of the vendor/project/service:

  • Accelerator – this is an accelerator of a large company. More of a lab or incubator than a real vendor
  • Product – this is a product. One that can be embedded into a service
  • Service – this is a running service that is hosted *somewhere*
  • Vendor – this is a vendor, probably sells a service on premise
  • Project – this is a project that can be licensed or adopted and integrated into a service
  • Research – this is a research organization
  • SDO – this is a standardization organization


The status of this vendor:

  • Acquired – this vendor got acquired by another vendor, and probably taken off-market
  • Planned – this service is planned and hasn’t been developed or launched yet
  • GA – this service is up and running
  • Beta – this service is still in its beta (or alpha) stage
  • POC – this is a proof of concept of a capability more than it is a service
  • Rumored – this vendor is rumored to offer or to plan an offering around WebRTC


WebRTC isn’t available in all browsers. This field indicates which fallback mechanism does the vendor uses, if any:

  • None – the service offers no fallback mechanism, running only on browsers supporting WebRTC
  • Flash – the service uses Flash technology where WebRTC isn’t available
  • Plugin – the service uses a plugin where WebRTC isn’t available


Footprint indicates on which platform the service is available:

  • Browser – the service is available on browsers that support WebRTC (might not support all of them due to interoperability issues)
  • Legacy Browser -the service is available on browsers that don’t support WebRTC using a fallback mechanism
  • iOS – the service has an iOS application or SDK
  • Android – the service has an Android application or SDK
  • Server – the service is rather agnostic to the WebRTC client side, as it is server-focused
  • PC – the service has a PC application (WebRTC got wrapped as a desktop application in this case)
  • Embedded – the service got WebRTC ported into an embedded device