Video conferencing allows two or more people to have real-time communication through voice and images. That is to say, real-time communication (synchronous communication) can be through audio, video, chat and many other opportunities that would help raise the level of interactivity between the participants of this video conference. This way of communication can be accomplished by using IP or telephony network infrastructure.

In order to make a successful video conference, it is enough for the end users to have the audio / video equipment (PC, headphones and listeners), and to determine the software they will use to perform such a service, for example: Skype, Viber, Facebook and many other providers which today have make it very easy the process of install them on your computer or phone today.

However, if in this case we would like to realise video conferencing with a larger number of participants (such as in primary classes, secondary classes or even Universities), then in addition to the end-user requirements mentioned above, for us the infrastructure that we have is also important. The latter is extremely important if we decide to provide such a service for the mass. Depending on the number of participants that such a platform / software will support, we also need to determine the topology we will use as an infrastructure technical component, which we must keep in mind.

In the context of this article, the word topology, or network topology, means the logical way of connecting network equipment to one another. Currently, we have three different topological approaches to deliver a video conference, Peer-2-Peer topology (hereafter P2P), Selective Forwarding Unit (hereinafter: SFU), and Multipoint Control Unit (hereinafter: MCU).

The number of participants in this video conference should be one of the defining criteria for selecting the topology through which we would provide the video conference. As the number of participants increases, so does the bandwidth which is required to transmit voice and real-time images to all participants. Further, this increase in the number of participants would also affect the performance of the computer’s CPU (hence their specifications) as real-time both voice and images must be encoded and decoded in convenient to be transmitted on one side, and adapted for the end user on the other side.

The P2P (mesh) topology could be used as a topology that would provide direct links between the participants of the video conference, in which case each participant would be linked to each other (See Figure 1). But if we had an increase in the number of participants the bandwidth load would increase, in which case any increase in participants after the third participant would degrade the call quality exponentially.

Figure 1. Peer-2-Peer Topology (P2P)

The SFU topology receives audio and video transmissions streams from all participants in a central device, and then the participants receive through this center the streams separately from all other participants. As the number of stream lines increases, the NSP topology in this case offers the possibility that participants can determine which stream line they wish to have with higher bit rate, and this determination would result in the degradation of the traffic for the rest of the stream lines. In this case, the SFU would adapt to each participant’s request, and would favor the quality of that participant’s stream line for which all other participants were designated. That is to say, of all the participants, the highest quality stream line would be dedicated to only one user. In this case it could be the teacher line, which would utilize the greater capacities to deliver online teaching (see Figure 2). 

Figure 2. Topology Selective Forwarding Unit (SFU)

Unlike the SFU, which receives and sends video and audio transmissions from the host participant to all other participants, the MCU topology accepts all streams, encodes and decodes them, then combines all streams within one stream, and then sends the combined stream to all participants through that shared channel (see Figure 3). 

Figure 3. Multipoint Control Unit (MCU).

MCU, unlike other topologies is particularly favored when dealing with more than 10 video conferencing participants, and moreover this topology can support signaling through SIP or H.323 protocols, the protocols used in networks to separate UDP traffic from that TCP, or more precisely, real-time traffic (which in this case is the voice that needs to be transmitted in real time), from that traffic that can be transmitted in non real time, which means there is greater tolerance (for example, browsing a website). The MCU topology, unlike the SFU topology, has a very low latency, so it is very rare that the interruption of voice, voice mismatch, image freeze, etc. can occur.

Now for all of you who are interested in using video conferencing for teaching and learning during this pandemic situation (COVID-19), the question arises:

1. If you want to provide video conferencing services through Cloud infrastructure?
2. If you would like to provide video conferencing services through infrastructure in your schools/ campuses?

Then follow the questions:

1. Do you want to provide this service through commercial providers that have their own Cloud infrastructure? Such as Zoom, Adobe Connect, WebEx, Microsoft Team, Google Meet etc, which fortunately at this time of pandemic have solidified with the entire global population and are providing limited services but at a satisfactory level for free.
2. Or do you want to offer this service through open source platforms? And then these platforms need to be provided by us with adequate infrastructure, either in Cloud or in-house.

Answering these questions would open me the way to write the second article, precisely to facilitate the decision-making process, and of course be aware of the trade-offs that you have to make at the time you position yourself at any potential answers.