About two years ago I bought my current VDSL + Wifi Access Point router, a Fritzbox 7590. It is still AVM’s flagship model to this date with 802.11ac Wifi-5 support and it is good to see that the manufacturer continues to develop the software to this day. Especially the Wifi functionality around Mesh and 5 GHz operation keeps getting better and better.
I’ve been waiting for this for 10 years! As I prefer to have as much of my private data flowing over the Internet in my own hands I’m running pretty much all of my ‘business critical’ web based services with open source software either at home or in a data center in Germany. The last piece of the puzzle that was missing was mobile and ‘casual’ end-to-end encrypted voice and video calling over my own infrastructure. I’ve had Nextcloud talk for a couple of years now and over the past two months have set up Jitsi and BBB instances for additional use cases. But all three solutions do not cover the ‘casual’ mobile calling experience where you just take your mobile phone and call someone else. Nextcloud, Jitsi and BBB would all have the potential to do that but non of them tried successfully covered this use case so far. But now Conversations, my mobile XMPP federated messenger app has made a quantum leap forward and has introduced voice and video calling!
Continuing my series on BigBlueButton server operation, I thought I spend a few words about how include those people in video calls that have old and not very powerful notebooks, smartphones or tablets. Most older devices still work ok in video conferences with 3 or 4 people. But in larger groups of 15-20 people, all showing their video feeds, less powerful devices start lagging behind and sooner or later quit entirely.
Most of you might know the feeling one has when that precious smartphone glides out of your hands, hits the street and goes straight to smartphone heaven: Horror followed by “damn, I haven’t copied my pictures yet”. The problem I had for many years is that backing up meant to know which pictures (or files in general) I had already copied and then only copying the new ones. That’s an exercise I didn’t even want to do once a month.
How nice would it be if it was just possible to rsync the phone to a backup drive. Turns out that this is actually possible!
While I wouldn’t use Zoom for private video conferencing, I do use it for public conferences (on a burner notebook…) and noticed that their Linux client program is very resource optimized. Even when showing a dozen videos and piping the local video camera stream into the cloud, CPU processor load on my Thinkpad X230 notebook from 2013 is around 30-40% over all cores with Ubuntu 18.04. Compare to that to the 100% load across all CPUs when using Jitsi or BBB in Chromium when 8 videos are shown and one video stream sent to the centralized server. This made me wonder a bit if the load on newer notebooks is lower.
When LTE was launched a decade ago, setting up measurements was a simple thing. When a connection is established, the network typically instructs the mobile device to measure the signal strength of the currently serving cell and the signal strength of neighboring cells. The result is either reported periodically or when predefined events occur. When I last looked more closely, most networks were using event A1 for reporting when the serving cell becomes better than a threshold, A2 when the serving cell becomes worse than a threshold and A3 and A4 when a neighbor cell becomes better than the serving or than a threshold. That was nice and easy. And then over time things got way more complicated and I didn’t look more closely anymore. And yes, there is event B1 and B2 for inter-RAT measurements when things get bad and the network needs to consider GSM and UMTS neighbors.
So here we go: In the past one and a half weeks, I’ve set up and then started running a BigBlueButton video conferencing server ‘pro bono publico’ in my quality time for a faculty of a non-technical institution. It’s been an exciting week for many reasons. The main one: Like many projects, the number of people who wanted to use it grew quite quickly.
Initially, I started working on a solution that would enable 3 to 4 lecturers throughout the week for some sessions. This quickly grew into 10 lecturers with some sessions in parallel. In the end, 16 lecturers showed up in the first orga call. A quick poll indicated the requirement for a system that could handle up to 5 parallel sessions with 60 people. On top, video between all people was seen as essential. From earlier experiments I knew that a 4-vCore VM could (only) handle a session with up to 20 people with the same number of videos between them. O.k., challenge accepted.
Here’s a quick follow up to my previous post about my first steps with a BigBlueButton server installation. Like Jitisi, getting a basic BBB instance up and running in a VM is straight forward. There is a good description over here with lots of details that you should definitely read before giving it a go. Before you do, here’s a super abbreviation of it with some additional tips and tricks thrown in for good measure:
While virtually at DIVOC and presenting how to install a Jitsi server, I also joined other sessions. Some of them where hosted with Big Blue Button (BBB), another open source video conferencing service. I heard from others that when it comes to ‘larger’ groups, say more than 20 people, it might perform better than Jitsi. So I decided to have a look at this system as well and install it on a server.
On Tuesday this week, awlnx and Krombel of Freifunk München (FFMUC) gave a virtual presentation online about their public Jitsi Server cluster installation and how they have set up the system. Currently, it serves well over 400 simultaneous participants in the evenings in 70 concurrent rooms. And with their 20 video bridge servers they say that they are prepared for over a thousand simultaneous users!