Exemplifying the streaming protocol “WebRTC”

The last blog discussed the “various streaming protocols and the battle between WebRTC and others.” We have been through the various streaming protocols and respective pros and cons of each. We can now infer WebRTC is the future of streaming protocols outweighing itself on others by offering real-time media communications between browsers and devices without installing plugins and glass-to-glass latency of less than 200ms, having the two most important factors while selecting the streaming protocols for your application.

Since we talked about the comparison of WebRTC with other streaming protocols, let’s continue the series and explore WebRTC technology deeper. In this blog, we will focus on multiple types of WebRTC topologies and their pros and cons.

What is WebRTC Topology?

WebRTC technology not only enables peer­-to-­peer communication, but it is also widely used to make a multi-participant call (multi-party video conferencing) and multiplayer gaming. When dealing with a multi-party call application, we must choose an efficient, scalable, and best suitable architecture or topology. However, the Full-Mesh (peer-to-peer) topology is the only connection type included in the WebRTC specification for most cases where mesh topology is insufficient. Majorly, WebRTC protocol has three topologies:

• Full-Mesh (peer-to-peer)
• MCU (Multipoint conferencing Unit)
• SFU (Selective Forwarding Unit)

Let’s learn more about other topologies which are majorly used by applications.

Full-Mesh (peer-to-peer):

Full-Mesh (peer-to-peer): In Full-Mesh architecture, every peer in the network sends their data to the other peers within the same network. In the entire mesh topology, every peer establishes a connection with every other peer in the network. Hence there is n*(n-­1) number of connections where n is the number of peers. For example, a complete mesh network with 4 users will have 12 connections, and one with 5 users will have 20 connections. In the Full- Mesh architecture, servers are not required, making this an affordable option. However, if there is an increase in participants, more bandwidth and CPU processing will be mandatory.

MCU (Multipoint Control Unit):

MCU architecture uses a centralized server that receives the encoded stream from all the participants and then uses transcoder and mixer to generate a single stream that will be shared with all the participants in the network. In the MCU topology, every peer establishes a connection with a centralized server. Hence there is n*2 number of connections where n is the number of peers. For example, an MCU network with 4 users will have 8 connections, and one with 5 users will have 10 connections. This helps the streaming process easier. Compared with the Full-mesh, The MCU reduces the network load for all of the peers in the network. However, the CPU server cost makes the MCU topology somewhat expensive.

SFU (Selective forwarding Unit):

SFU acts like a router of media; it receives the incoming encoded media streams from all users and then decides which particular stream needs to be sent to a user. In the SFU topology, every peer establishes a connection with a centralized server. Hence there is n*n number of connections where n is the number of peers. For example, an SFU network with 4 users will have 16 connections, and one with 5 users will have 25 connections. SFU gives flexibility to the user side while reducing the CPU computational cost on the server-side. The above two factors make SFU a more popular and cost-effective option that is scalable with WebRTC applications.

Comparison of Full-Mesh, SFU and MCU Topologies

Inferring from the above table, it is clearly seen that full-mesh topology is not suitable for scalable architecture (large network) as the bandwidth required for the users is quite high. Eventually looking at cost-effective options, we have the SFU and MCU.

SFU or MCU? – Architecture Scalability and Cost-effective

How SFU outweighs MCU

• The SFU architecture can work with asymmetric bandwidth, which requires higher downlink bandwidth than uplink bandwidth.
• With SFU, it is reasonably easy to add multiple streams or participants to the conference.
• IN SFU, with the help of the Simulcast technique or SVC codec, every participant can send multiple versions of the same media stream to the centralized server, but the SFU server will forward a single version of the stream as per the user’s screen layouts on their devices respectively.
• The server cost in SFU is minimal as most compute-heavy operations are offloaded on the client device, making it cost viable.

Hybrid-MCU/SFU WebRTC topology:

Apart from above mentioned standard topologies, we have a fresh perspective of one more topology that is “Hybrid WebRTC topology.” It is a combination of SFU and MCU architecture. This topology is not a WebRTC standard topology, but we can develop our custom design. The hybrid topology will guide the application to utilize the MCU or SFU architecture as defined business logic using the topology selector.

The hybrid-MCU/SFU topology allows the media stream delivery based on preferences based on the preference optimized for the individual client. For example, in cases where the client is a mobile or SIP device, the media gateway will deliver a single MCU-type mixed stream. On the other hand, for WebRTC clients capable of handling multiple streams without restrictions on bandwidth or compute, the media gateway will deliver forwarded/routed-type streams. Additionally, if the number of participants in the call is more than 200, most of them with low bandwidth and computing devices, then the media gateway will deliver a single MCU-type mixed stream. So we know we can always come up with our business logic depending on factors like user-device type, available bandwidth, compute at the user end, number of participants present in the conference call, user’s geographical location, and subscription service plan selected by users. Some of the most popular WebRTC open-source SFU frameworks are Jitsi-meet, Janus, Media Soup, Med ooze, and Kurento, which provide higher flexibility to users and are affordable.

Greendot – GS Lab’s Jitsi-meet based video conferencing solution

GS Lab is a pioneer in integrated video-enabled offerings like Conferencing and Collaboration, Enterprise communication, Video Surveillance Solutions, and Media Streaming. In the last 18 years, we have developed numerous communication products that cater to various Industries. We have actively contributed to the open-source community with over five open source contributions in the communication domain. Recently, we have developed Jitsi-meet-based one-stop video conferencing solution known as Greendot. It is a free open-source multiplatform for VoIP/Video conferencing/IM applications and is compatible with WebRTC. The Greendot has quite flexible and scalable set of features for easy application development/integration. Know more about Greendot.

• Learn more about GS Lab at www.gslab.com
• Know more about our expertise in WebRTC technology and how we can help you accelerate your business transformation