Introduction

This page provides a bird eye view of information flow in WebRTC.ai ecosystem. Please check Get Started guide to build a fully functional video conferencing app in 4 easy steps.

Taxonomy

For the original definitions of WebRTC and related terms please check the official website https://webrtc.org/. Here we mention only the terms useful in the context of WebRTC.ai

Name	description	Uniqueness	Identifier	belongs to
Client	An entity responsible for managing the account and billing at WebRTC.ai . Similar to an organisation	always	cid	N/A
Session	A group of participants in a single video call or webinar. Similar to meeting room.	real-time	sid	cid
Participant	A device that can publish its local media stream ( e.g webcam, screen-share) or subscribe to other participants' streams	real-time	uid	sid
WEB_ONLY API KEY	Required to Authenticate the create/join session requests. WEB_ONLY Keys are attached to predefined domains only (e.g. app.webrtc.ai) and works only if the SDK is being used on that domain only. If you are building a WEB only application then no need to use any backend code at your end. Recording is enabled/disabled at KEY level only.	always	WEB_KEY	cid
Media Stream	A binary data stream that carries audio/video data from client to server and vice versa. (e.g Webcam Stream, screen - share Stream)	always	feed_id	uid
Video Element	A native DOM element that encodes/decodes and renders a Media Stream.	N/A	target Video EleID	N/A

real-time uniqueness means the same value of the identifier can be re-used at different times. E.g. sid can represent recurring meeting name (Mathematics_XI_B) and uid can represent phone number of a participants.

Cloud architecture and information flow

All WebRTC connections are negotiated and maintained between the SDK and a node within the Media Cloud. All Servers act like a low latency, 5 gbps peer with every client. Nodes reside in 6 globally distributed regions interconnected with VPC peering, to provide lowest latency and high availability. The traffic enters the cloud via Anycast IPs maintained by edge servers in 96 cities across the globe.

The primary way to connect with the cloud is over a websocket. SDK would maintain a persistent connection for a robust signalling system and would restart in case of network downtime.

SDK : A robust layer over native browser APIs

The Javascript SDK takes care of all the heavy lifting from the client side. The primary role of the SDK is to maintain a stable connection with the cloud, capture/render the media streams from/on the client side, negotiate RTCPeerConnection with the cloud, and optimise the media quality based on the available bandwidth.

A high-level API is provided to the client applications for session initialisation, publishing self feed (webcam/screen share) or subscribing to other participants. Media streams are directly sourced into the HTML video elements provided in the API call. Client applications would take care of style and look video element thus ensuring seamless integration with their own brand identity. SDK supports live communication and recording of audio/video media streams, screen sharing and binary data-channels.

The client application

Clients can include the SDK at runtime via CDN-backed endpoint or pre-compile it with the application. Most of the methods exposed by the SDK are asynchronous and returns a Promise. The apps need to initialize the SDK with an WEB_ONLY API KEY or JWT tokens. To publish or subscribe to a stream the API would require a mandatory HTML video element that would be populated with the Media Stream. The apps would listen for various events on the session object that arises when someone joins or leaves the session.