PlatformRTC is a platform as a service for EasyRTC clients to use in place of their own EasyRTC Server and STUN/TURN servers. Rather than operating on a single server, it is delivered by a set of microservices spread across a distributed network of servers in the cloud. It delivers a highly scalable and crash tolerant environment with a broader set of services including call control, room control, STUN and TURN services.

Please contact us for pricing, availability, or if you have any questions.

Contact Us

What is PlatformRTC?

Messaging and the Role of the Servers

In EasyRTC, the intelligence for establishing calls was located in the clients, the server only relays messages and does some checking of their contents.

PlatformRTC moves most of the intelligence to servers. A client requests a call and the servers responds by telling each peer in the call that a call is starting and what the peers role in the call will be (offerer or answerer). The peer then responds to these messages. If the peer doesn't respond to a message at any point, the servers are aware of it and can tell both sides that the call failed. Part and parcel of this is that a peer can request a call not just to specific peer (as was the case of EasyRTC Open Source), but to a member of a class of peers (such as headless clients used for testing peer connections or workers in a call support center), and reconnecting calls (transparently to applications) is now possible.

Rooms in PlatformRTC are made more powerful by managing calls for you through a number of new room options. It is no longer required that every peer know of the identities of all others in the room.

Monolithic versus Micro-Services

In EasyRTC, the clients and servers were each single modules that used a number of libraries. It was difficult to add a new message type to the system without knowing how the entire system worked (on both client and server sides).

PlatformRTC is broken up into micro-services on the servers, and complimentary modules on the client side. Call control, room control, and authentication can now be managed and scaled independently. The complexity of each service is reduced while increasing reliability.

One benefit of this approach is that new functionality can be added to one microservice (or an entire new service can be added) without impacting the stability of the other microservices. Another benefit is that a developer no longer needs to understand the entire system, just the service they want to change.

Server Scalability and Crash Tolerance

EasyRTC always had scalability issues because the entire server ran in a single node js instance. In theory, you could use a load balancer so that clients using different rooms actually got connected to different server instances based on what room they were in, but that had the problem that a client could only be in a single room, and a server going down would still kill the connections of all the clients it was serving.

PlatformRTC improves on this by storing all state information in a database instead of using memory only data structures. This means that over the course of a call, a client could be served by a different instance of a microservice on each message it sends; clients no longer have a long term connection to a service. If a microservice goes down while serving a particular message, the message it was responding to is reissued to another instance of the microservice so that the only effect on the client is a delay in receiving the response. Additional microservices can be started when load increases, and unneeded microservices shut down when load decreases.

Transport Agnostic

EasyRTC is very tied to the use of WebSockets and

PlatformRTC uses a publish/subscribe model which can use a variety of underlying transport mechanisms simultaneously. For example, currently, browser clients use websockets underneath and native clients use TCP sockets. This is very useful when dealing with multiple architectures since you can pick and chose your transports for different architectures according to which is most stable, has the best API, has the least restrictions, etc.

PlatformRTC Features

The table below compares PlatformRTC to EasyRTC.

Feature PlatformRTC EasyRTC
General Architecture
By splitting services up, each can be specialized and scaled as needed.
Micro-services architecture with separate services for authentication, room, and WebRTC call control. Single Node.JS Module
Multiple transport methods allows for different types of clients and reliability requirements.
Agnostic. Includes support for WebSocket, AMQP, MQTT, and REST.
Server failover / concurrency
Newly spawned servers know the state of all calls, allowing them to handle any requests without interruption.
Yes. State held in Redis. None
On-Premise Servers
EasyRTC servers can be used in your own infrastructure, which can be required for sensitive applications.
No Yes
Private Cloud Servers
EasyRTC servers can be installed in the cloud, giving organizations control over which data centers are used.
No Yes
Managed Cloud
Managed microservices and scalable servers.
Yes No
Managed STUN / TURN Servers
STUN and TURN services increases call reliability for various network configurations.
Yes No
Multi-Tenant Servers
Eases privacy and security concerns.
Yes No
Smart Call Management
Better WebRTC call reliability and failover.
Included Not included. May be custom coded.
Browser JavaScript Client
Support for any WebRTC enabled browser.
Yes Yes
iOS Native Client
Write native apps for iOS.
Yes No
Linux C++ Client
General Linux client, for WebRTC projects beyond simple conferencing.
Yes No
RTSP -> WebRTC Linux Video Client
Ingest video feeds from local RTSP based security cameras.
Yes No
Video File -> WebRTC Linux Video Client
Read local video files and play them to other EasyRTC peers.
Yes No
Peer-To-Peer File Transfer
Confidentially transfer files between peers.
Yes Yes
Peer-To-Peer Messaging
Confidentially transfer text messages between peers.
Yes Yes
Peer-To-Peer Custom Fields
Allows state to be securely shared between peers. Useful for custom collaboration applications.
Yes No
Custom Field Levels
Attach custom variables to various objects to share with others.
Application, Call, Room, Room-API, Peer Application, Room, Room-API
Custom Fields use JSON Patch
IEEE standard (RFC 6902) method for transferring full or partial data changes.
Yes No
Peer Discovery
How peers can find out about others.
3rd Party Service, Query, Room Room only
Room type: Mesh
Every participant in a room automatically connects with every other participant for two way communication.
Included Not included. May be custom coded.
Room type: Broadcaster
The broadcaster automatically connects to every other participant for one way communication.
Included Not included. May be custom coded.
Server Controlled Call Management
Call management at the 'Call' level provides greater flexibility towards call automation, reliability and failover.
Yes Not included. May be custom coded.
Peer-Connection Failure Management
Users experience a more seamless connection, even with network interruptions.
Yes. Can gracefully reconnect call. No
Peer to Server Connection Management
Reauthenticate and reconnect lost calls when network conditions change, such as switching from WiFi to Cellular Data.
Yes No

Please contact us if you have any questions.

Contact Us