Video conferencing with BigBlueButton

While social distancing often comes naturally to free-software developers, there are still times when we wish to talk to each other. In the absence of community conferences, the next-best alternative is often video conferencing. While video conferences tend to be held using centralized, proprietary systems, there are free alternatives as well. LWN recently looked at Jitsi but this effort did not stop there; next on the list is BigBlueButton, a system that is oriented toward the needs of online educators but is applicable beyond that use case.

BigBlueButton is not a new project; it has been under development since 2007. That history shows in a number of ways; for example, the actual conferencing component was originally implemented in Flash and has only recently been supplemented by an HTML5/WebRTC-based solution. The code is licensed under the Lesser GPL; the web site doesn't say which version, but comments in the code say version 3 or later. The code itself is a massive collection of Java, Scala, and JavaScript (at least) code — almost 1,800 directories worth.

Installing BigBlueButton

The heavyweight nature of BigBlueButton shows in the installation instructions, which go on at some length. There is also a script to do all of that work, along with a suggestion to use the time-honored "wget|bash" execution method. Your editor used the script, but only after eyeballing it (thus guaranteeing that it is secure) and making a change as described below.

The system's server requirements are quite specific; in particular, only the Ubuntu 16.04 release is supported. BigBlueButton wants at least 8GB of memory ("with swap enabled") and four CPUs. The installation script will refuse to run on any other distribution or if the system has less than 4GB of installed memory. Your editor capitulated on Ubuntu 16.04 but, being of a generally parsimonious nature, tweaked the script to make it accept the low-end 2GB virtual server used to test the system.

The Ubuntu 16.04 requirement is justified in the name of stability, and one can easily imagine that the developers wouldn't want to support this towering stack of software on multiple platforms. But that is an ancient distribution at this point, and it is losing support in one year; there is going to have to be a mass migration of BigBlueButton systems over the next twelve months.

The installation script takes about a half hour to get its job done. This work includes setting up a number of third-party repositories for needed components; the installation instructions correctly note that "the default version of ffmpeg in Ubuntu 16.04 is old", for example, so the script obtains a more current version from elsewhere. By the end of the process, not only was the software installed, but the script had helpfully obtained a TLS certificate for the server from Let's Encrypt. Those trying this at home should note that BigBlueButton can take several minutes to actually get started after being launched; they should not assume quickly that the installation has failed.

While BigBlueButton handles the conferencing tasks, it does not concern itself with front-end tasks like managing "rooms" or authenticating users. There is, instead, a reasonably well-documented API that is intended to be used by the front end. Given its roots in the educational community, it is not entirely surprising that applications like Moodle use this API to integrate with BigBlueButton. For those wanting to run a standalone system, there is a front end called Greenlight that can optionally be installed with the BigBlueButton installation script.

Greenlight, as it turns out, is a Ruby-on-Rails application, adding nicely to the menagerie of languages running on the server. And, while the installation script loads BigBlueButton directly onto the server, Greenlight gets installed as a Docker container. That makes management a bit interesting; after some digging, it turned out that the way to create an initial administrative account on the server is a command like this:

    docker exec greenlight-v2 bundle exec rake \
           user:create["root","bbb-admin@lwn.net","password","admin"]

Running this command promptly threw the server into an existential out-of-memory crisis, making it clear that the project was serious when it said 4GB is necessary — even before a single video conference is established. Once this little obstacle was overcome, the system was up and running.

Then what?

Connecting to the web server, once it gets going, yields a generic "about Greenlight" page and the opportunity to create an account. And the inevitable "yes I agree to let you use cookies" box to check, of course. The default configuration will happily let users connect without encryption, with no redirection, despite the fact that HTTPS works just fine. Account creation is straightforward; by default, anybody can create an account on the site.

Once logged in, the user is placed in the "home room". A big, blue (naturally) "Start" button is there to launch a meeting in that room. Users may create other rooms at will. Each room has its own name, but that name is not useful for others wanting to join a session in that room; instead, there is a special "invite URL" that must be handed to potential participants.

Hitting the big, blue button will launch a meeting in the selected room. The first question all participants get is whether they only want to listen to what is going on or send audio as well; clearly the latter is needed for any sort of interactive experience. What follows is the "echo test", where the microphone is fed through to the speakers (generating some nice feedback if a headset is not in use) and asking the user to confirm that it is working as expected. As a one-time feature this is nice, but the system requires this step every time one enters a meeting room; given that the user has already agreed to cookies, it would seem possible to set a cookie saying "audio worked the last 20 times, we can probably skip the test now", but that doesn't happen.

A separate step is required to send video. At this time, the user can select which camera to use and the resolution of the stream to be sent; there is no easy way to change that resolution afterward. It's worth noting that BigBlueButton defaults to relatively low (640x480) resolution, unlike Jitsi, which tries to cram as much video data as it can down the pipe. The lower resolution seems entirely adequate, and will certainly reduce the bandwidth requirements overall.

The conference screen comes up with a presentation window by default; video windows are squeezed in as participants make them available. Video and audio quality seem generally good. If all you want to do is to have a conversation among a group of people, the result is like a lot of other video-conferencing systems, especially once one sends the presentation window away to make more space. BigBlueButton uses a tiled view showing all participants with a video feed. One can "focus" on a specific participant (making their window bigger) or make one person take up the whole screen. There does not appear to be a mode where the current speaker is shown, which is arguably not a huge loss.

There is a lot more to BigBlueButton than just video chat, though. The presentation window really is set up for running through presentations; it is also relatively straightforward to upload a presentation in (for example) LibreOffice format. Only the participant designated as the "presenter" can do this, though; the room moderator can move the "presenter" token around at will. The presenter can also use a rudimentary set of tools to draw on the slides if desired.

There is a "multi-user whiteboard" mode that the presenter can turn on; it makes the drawing tools available to all participants in the meeting. Everybody can have fun writing graffiti on the presentation slides at that point. There does not appear to be a way to have a shared whiteboard that is independent of the presentation slides; if all one wants is the whiteboard, the answer appears to be to upload a "presentation" consisting of a single blank page.

On the left is a column of icons for the participants; those indicate whether they are sending audio among other things. Each participant can set a "status" in their icon, indicating sadness or confusion or, by "raising their hand", a desire to speak. The icons are small and the status is not easy to see, though; if the number of participants is large, picking out the one with their hand raised seems like a challenge.

The room moderator has some extra options attached to the icons, including the ability to turn any participant into the presenter. Participants can be muted, either individually or all at once. There is also an option to promote other participants to moderator status, but that feature did not appear to actually work.

There is a chat feature, naturally, for out-of-band text conversations; those can be either shared or private. The moderator has the ability to lock down private chats, though, in an attempt to focus the attention of students who surely have no other way to send messages to each other. There is a separate area for shared notes. BigBlueButton also supports closed captioning — in multiple languages simultaneously — but users have to provide the person actually entering the caption text.

The moderator can click a button at the top of the screen to record the session; all participants will be notified when this happens. Once the meeting ends, the server will launch a long-running FFmpeg process to convert the recording to an exportable format; the result will eventually appear on the room owner's screen. Recordings are private by default but can be made public. It's worth noting that the recordings are not just a video file; they are a sort of web application that includes the session notes, chat text, slide thumbnails, and more. Getting a plain video file that can, for example, be uploaded elsewhere does not appear to be directly supported.

There is a "breakout room" feature available to the moderator, who selects a number of rooms to create and how long they will exist. The moderator can also assign participants to specific rooms or hit a button to scatter them randomly. Once the breakout rooms are launched, participants are effectively jailed within them until the selected time period expires; there does not appear to be a way to end the exercise ahead of schedule. Recording does not appear to work within the breakout rooms.

The system has a simple "polling feature" that the presenter can invoke; each participant will see a set of buttons and can pick the one that corresponds to their answer to whatever question is being asked. It's worth noting that while participants cannot see how others vote, the presenter can. The presenter can "publish" the results, ending the poll and placing the vote counts (but not individual votes) on top of the presentation window.

Unlike Jitsi, BigBlueButton does not have an app for mobile devices; instead, the web interface is responsive and scales itself appropriately. For the most part it works well, with the occasional glitch. Some options, for example, cover the discussion with a dialog; Android users will naturally hit the "back" button to make that go away, and will be disappointed when it backs them out of the meeting entirely. In general, though, the developers seem to have done a good job of mobile support.

All told, BigBlueButton provides a reasonably full-featured and solid experience, whether the intent is giving presentations or having a group meeting.

The management side

One of your editor's complaints about Jitsi was the lack of overall management tools; there are few ways for a server administrator to even know what is happening on the system, much less apply controls to it. BigBlueButton seems to be rather more developed in that regard.

By default, anybody can create an account, anybody with an account can create rooms, and anybody with the URL for a room can join into it. All of those can be changed, though. Account creation can be made invitation-only, or administrator approval can be required. Specific privileges (the ability to create rooms, manage rooms created by others, tweak system settings, etc.) can be given to users as desired. Server administrators can see all of the existing rooms and their status — and step into any of them if desired.

The owner of a room can set its access policy. An access code can be set on the room; that is a six-digit number that is chosen (seemingly randomly) by the system, rather than the owner. Participation can be limited to users who have authenticated with the site. It's also possible to require moderator approval for anybody wanting to join a room. Moderators can also, of course, boot participants out of a room if needed.

Like Jitsi, BigBlueButton claims to be able to interface with a SIP server to implement dial-in access to meetings; this is not a feature that your editor was able to try out.

Finally, it's worth returning to resource usage. Running BigBlueButton on that 2GB server worked in the end, and a number of meetings (up to about ten streams) have been hosted on it. The system swapped rather heavily but was able to get the job done. The run-time resources required to add another participant to a meeting don't seem qualitatively worse than Jitsi's; BigBlueButton requires a bigger base to run on, but seems to scale similarly. Its bandwidth requirements are lower, presumably due to the lower-resolution video settings. (It should be noted that some scaling issues only turn up with large meetings; your editor doesn't have enough friends to run one of those.)

To summarize, while both Jitsi and BigBlueButton are capable video-conferencing systems, BigBlueButton appears to be a more solid and feature-complete offering. In particular, the administration features and shared whiteboard capability stand out. The free-software community often struggles to create top-quality graphical applications; here we have (at least) two of them. It would appear that there is no real need to be using proprietary solutions in this area.

---

to post comments