Using WebRTC protocol

WebRTC (Web Real-Time Communications) is a P2P (peer-to-peer) protocol for bidirectional secure real-time communication between the two clients.*

Lets's break it down into sections. P2P (peer-to-peer) tells us that two agents (clients) interact directly with each other without the third party interfering. Bidirectional refers to functioning in two (opposite) directions. Secure means that the connection is encrypted by one or more security protocols. Real-time communication stands for nearly instant information exchange without or negligibly low delays.

WebRTC has its advantages:

ultra-low latency (less than a second),
obligatory encryption with DTLS and SRTP protocols,
open-source standard,
no need to install any additional plugins or applications, etc.
support for adaptive bitrate streaming.

Try it online

How WebRTC works

WebRTC protocol is used for data exchange between the two browsers (no plugins or any extensions needed) or applications that support that protocol via the "one-to-one" or "client-client" type of communication. For example, visiting the same website, two browsers can interact with each other with WebRTC. That is why it is great for voice and video calling (Zoom), content sharing and more.

However, introducing Flussonic as a signalling server between the peers, you can easily arrange "one-to-many" communication. Signaling server is a media mediator that manages the connections between devices. Thus "client-client" type of connection becomes "client-server-client". As a result, "one-to-one" becomes "one-to-many", offering more to functionality to the user.

Flussonic as WebRTC signalling server

For the clients, or agents, to start communicating with each other using WebRTC, four sequential steps are taken:

Read more about these steps in the official guide on creating your WebRTC app.

Publication and playing with WebRTC. WHIP and WHEP standards

For a long time, WebRTC has not been adopted in broadcasting and streaming industry because it has no standard signaling protocol and is too complex to be implemented in broadcasting tools and applications. To solve this problem, a new WHIP (WebRTC-HTTP ingest protocol) and WHEP (WebRTC-HTTP egress protocol) protocols were designed. WHIP is designed for publishing streams to Flussonic and WHEP is for playback from Flussonic.

These protocols provide a simple and media server-agnostic way of injecting WebRTC streams that can be easily integrated in existing broadcasting tools. The whole WebRTC negotiation process in WHIP can be reduced to an HTTP POST request to send the SDP offer, and a 200/202 response from the media server to return the SDP answer instead. At the same time, WHIP and WHEP keep all the advantages of WebRTC such as low latency, resilience, bandwidth adaptation, encryption, supporting common codecs, adaptive bitrate, and so on.

In fact, the WHIP and WHEP protocols are almost identical. The only difference is that WHEP supports two negotiation modes: 1) a POST request as in WHIP and 2) an empty POST + subsequent PATCH. The second method allows the server and client to pre-negotiate the characteristics of the stream, such as audio and video codecs, so that the client does not have to allocate resources for all supported codecs. Read more about the data exchange process for establishing a connection between the server (Flussonic) and the client application: WHIP / WHEP (the Overview section).