Skip to content

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 adjustment
  • Encryption
  • Support of common codecs
  • Adaptive bitrate, and so on.

Flussonic evaluates the state of the WHIP and WHEP sessions by the payload.

  • To keep WHEP session (play session) alive, Flussonic must receive ICE binding request or RTCP RR (Receiver Report) message at least once every 30 seconds.
  • To keep WHIP session (publish session) alive, Flussonic must receive either RTP or RTCP SR (Sender Request) message, or ICE binding request at least once every three seconds.

Read more about the data exchange process for establishing a connection between the server (Flussonic) and the client application in the Overview sections of the following specifications:

See also: