Any ApiRTC solution involves at least two software parts: the Client Application and ApiRTC PaaS Platform.

Architecture schema (refresh page if schema does not appear)

Client Application

The client application is the web or mobile application that connects users together. It allows them to share messages or media, and it displays messages or media from the others.

ApiRTC let's you build web and mobile applications, using any modern application framework or native languages.

Application Backend

The application backend may require some interactions with ApiRTC Platform.

ApiRTC PaaS Platform

The ApiRTC platform is compound of different systems. All together they bring a full featured communication system for various applications.

More details


ApiRTC features SFUs servers to enable large number of users video conferences to happen

Tell about peer-to-peer, mesh mode, star topolofy SFUs... :

Basic WebRTC applications are using full mesh topology. Each client must :

  • encode and send their stream(s) to each remote peer
  • receive and decode every remote peer stream(s)

The CPU load and the required bandwidth increases linearly as the number of peers and streams grows. This topology is unsuitable for applications where larger groups of peers need to be connected at once.

ApiRTC enables the usage of a star topology by providing SFUs (Selective Forwarding Units) that acts as a central server that relays each peers’ streams.

In ApiRTC, media streams flow through ApiRTC infrastructure SFUs.

But you can control that my enabling meshMode, and event force it remain mesh. Otherwise ApiRTC will automatically try to switch to star topology architecture.

In order to realize a WebRTC application, one must establish a connection between the browsers that want to communicate. WebRTC provides the solution for the media plane but does not implement the signaling, i.e. how one client’s information should be sent to remote peers in order to initiate connections. ApiRTC CCS implements a signaling server using WebSockets. The browser and server interaction is event-based : the browser does not have to poll the server for a reply every time data have to be exchanged.



Users management

When it comes to Users management, one can decide to use his own or leverage with ApiRTC's.

Media storage

ApiRTC also includes databases for Media storage, providing a secure way to store exchanged data or conversations recordings.

To send and receive data to another browser the client must have some specific information. The most important information is the client’s public IP address. Each client or browser must know this information about each other in order to receive an incoming connection from another client.

Sometimes, users might face connectivity issues because of different IP networks where Firewalls and NATs (Network Address Translators) could include specific network policies that will not allow RTC communications.

To overcome this, WebRTC recommends the use of a STUN server. A STUN server allows clients to find out their own public IP address and which type of NAT they are behind. Sometimes it can be hard to fetch the information, depending on the NAT, and in that case, a TURN server can help the process.

In order to solve this kind of network connection scenario, we need to use ICE (Interactive Connectivity Establishment) protocol and it defines a systematic way of finding possible communication options between a peer and the video gateway.

  • ICE (INTERACTIVE CONNECTIVITY ESTABLISHMENT) is a protocol used to generate media traversal candidates that can be used in WebRTC applications, and it can be successfully sent and received through Network Address Translation (NAT)s using STUN and TURN.

  • STUN (Session Traversal Utilities for NAT) that complements ICE through NATs using UDP protocol. STUN allows applications to discover the presence and types of NATs and firewalls between them and on the public Internet. It can be used by any device to determine the IP address and port allocated to it by a NAT.

    Typically A STUN client can send messages to the STUN server to get the Public IP and ports information then STUN server retrieve that information. Using this Public IP and Port information clients will make a peer to peer communication through the internet.

  • TURN (Traversal Using Relays around NAT) is a protocol that assists in the traversal of network address translators (NAT) or firewalls for webRTC applications. TURN Server allows clients to send and receive data through an intermediary server. The TURN protocol is the extension to STUN.

In a few cases, client communication endpoints are stuck behind different types of NATs, or when a symmetric NAT is in use, it may be easier to send media through a relay server and its called the TURN server.

ApiRTC provides both STUN and TURN servers to address theses WebRTC requirements.



ApiRTC Dashboard is the portal to access your account on ApiRTC platform.

It gives you access to the configuration of your Enterprise(s), Users and services.