In short Jitsi Videobridge is the media server of Jitsi Meet. It’s a XMPP Server component and most importantly it’s WebRTC compatible and opensource.
When building conferences with WebRTC which are not peer to peer most solutions adapt some sort of media server which act as the central server which handles all the streams of clients either by forwarding the incoming streams to all clients (SFU) or mixing the incoming streams and forwarding a single stream to everyone(MCU). Jitsi Videobridge follows the first approach as it forwards the incoming streams to all clients who are connected to the videobridge.
SFU modal is resource efficient compared to MCU modals. As per jitsi’s performance evaluation test a single videobridge can handle 1000 video streams at 550 Megabits 20% CPU which is really good. The other good side of this is that the quality of the videos is expected to be great as the videobridge does not do any mixing and simply relays the streams. The down side of this would be on the client side as they would experience higher CPU and bandwidth usage as the number of participants grow. Jitsi tries to minimize this by having simulcast and features like Last N
Jitsi has given its REST version of Colibri which can be used to get real-time statistics about the meetings in the conference. Details like ongoing conferences, details of individual conference, and other statistics like rtp loss, bitrate download, audio channels etc. can be received. You can refer the API here
Out of the components of jitsi, videobridge is usually the first that needs to scale with increasing demand. Since it’s the media server as mentioned above bandwidth becomes a limiting factor in most scenarios (specially when using servers from aws) There are two ways of scaling the videobridge.
In vertical scaling instead of adding more servers, the current server is upgraded to higher specs. If the traffic is uniform this solution would work to the threshold limits of the server. But when the traffic varies the high specs could be an overkill and costly since the server needs to keep running for the ongoing meetings.
This is the popular or the recommended way to scale the videobridge. We have a detailed article on how to achieve this on aws here In short adding more videobridges means the system can handle more simultaneous participants. If octo is configured participants from the same conference can also be divided among the bridges. If autoscaling is configured, the servers will scale in accordance with traffic.