BigBlueButton Overview

What is BigBlueButton?

BigBlueButton is a free and open source web conferencing system, primarily targeted towards online lecturing by providing a virtual classroom environment, and tools for small group collaboration. However, BigBlueButton is by no means limited to classroom settings and small groups; it just means that the core features and components of BigBlueButton were developed with this target demographic in mind. The BigBlueButton name comes from the notion that starting a web conference should be as simple as pressing a metaphorical big blue button.

Who Develops BigBlueButton?

BigBlueButton was started in 2007 by Richard Alam, who at the time was a Master's student at Carleton University. Since then, many other individuals and organizations have become involved. The core team of developers come from Blindside Networks, Seneca CDOT, and Mconf.

What Features Does BigBlueButton Have?

BigBlueButton contains a set of components, called "modules", each containing a bunch of features. Such modules and features include:

The users module, that contains and displays the list of users in a meeting, along with their state (whether they are a presenter, moderator or normal viewer, whether they are sharing any media, whether their permissions are restricted in some way, etc..).

The video module, where people in a meeting can share their webcam to be viewed by everyone else in the meeting.

The audio module, that allows people in a meetings to share their microphone and speak to everyone else in the meeting.

The desktop sharing module, that allows the presenter in a meeting to have other users in a meeting view what they are doing on their screen.

The chat module, that allows users to broadcast chat messages to everybody in the meeting (public chat), or to send chat messages only to a specific user (private chat).

The presentation module, that allows the presenter of a meeting to upload documents (a PowerPoint presentation or PDF, for example) to be viewed by everyone else in the meeting.

The whiteboard module, that gives the presenter the ability to manipulate a canvass overlaid on top of the presentation window, allowing them to write, draw shapes, and insert text onto the virtual whiteboard.

The polling module, which allows a presenter to query participants, letting them vote on questions asked, and to view the results.

Lock Settings, which allow moderators of a meeting to restrict some users' access of the modules. For example, a moderator can disable webcam sharing, or chatting between participants.

BigBlueButton Architecture

Background Information

BigBlueButton was initially a Flash application. The server, written in Java (now moving to Scala), sat on a Flash media server called Red5, and the main client was a Flash web application (the "Flash client") that was downloaded by the browser upon joining a BigBlueButton meeting. As a Flash application, this meant that users had to install a Flash Player into their web browser in order for them to use it (like old YouTube videos). Though the main BigBlueButton client is still Flash based, all of the new features that HTML5 requires browsers to be able to support natively (without having to install plug-ins) allowed developers to begin work on a second client for BigBlueButton, that used only the built-in capabilities of web browsers (the "HTML5 client"). Additionally, around late 2013, development began on a cross-platform mobile application for Android and iOS that allowed people to join a BigBlueButton meeting from mobile devices (the "mobile client"). Both the HTML5 client and the mobile client are still under development.

Server-side

See this for a recent overview of BigBlueButton's server-side architecture. Behind the scenes, the BigBlueButton server uses the following technologies:

Red5: a Flash Media Server, with "room management" (a Red5 room corresponds to a BigBlueButton meeting) allowing easy handling of message sending and streaming to only those users who connected to a specific room. Red5 holds the following BigBlueButton components:

BigBlueButton-Apps: this IS BigBlueButton :) It holds the master state of all meetings on that server

BigBlueButton-Video: the video application, which sends webcam streams from one user to all the others connected to that meeting and using Flash video.

BigBlueButton-Voice: the audio application, which sends audio streams from one user to all the others connected to that meeting and using Flash audio. In order to send the audio data to clients using WebRTC audio (the HTML5 client, and now Flash clients have the option of using WebRTC audio if their web browser supports it), BBB-Voice connects each Flash client using Flash audio to FreeSwitch (see below), and sends the audio data to FreeSwitch which transcodes the audio data to a format that clients using WebRTC can use.

BigBlueButton-Web running on Grails and Tomcat: BigBlueButton's web API, allowing programmers to create meetings, join meetings, get configurations for a meeting, get information to set the state of the client when joining a meeting, to use the presentation services for uploading presentations, and to use the recording services to record meetings.

Redis: a key-value store used by BigBlueButton to communicate between the different server-side components, and to record all of the events of a meeting. Redis provides a publish and subscribe ("pub-sub") messaging system, that allows applications to subscribe to channels, which means every message published to that channel will be received by all subscribers of that channel. Try this interactive Redis tutorial!

FreeSwitch: used by BigBlueButton as a VOIP server to manage voice conference calls between WebRTC audio clients, connecting them and streaming their audio data to others in the same conference. Additionally, since Flash Audio and WebRTC audio use different audio codecs (Speex vs Opus), FreeSwitch is used to transcode between these two codecs, and send the audio data to BBB-Voice for repackaging and delivery to those Flash clients that are using Flash audio (Flash clients needn't use Flash audio, but can now use WebRTC audio).

Meteor.js on Node.js: Node.js is JavaScript environment which is not a web browser. This is the server to which HTML5 clients connect. It communicates with Red5 through Redis.

Nginx (pronounced "engine-x"): used as a reverse proxy, to forward HTTP requests to other applications on a BigBlueButton server, depending on the structure of the URL.

BigBlueButton Development

For New Developers: Getting started on BBB

***Under construction: write something here!!***

First, you will likely want to subscribe to the following BigBlueButton mailing-lists:

Next, since all of the source code for BigBlueButton is hosted on GitHub, you should try to gain a rudimentary understanding of how to use Git. Nothing too fancy, but at the very least, you should know how to clone repositories, create and navigate local branches, add files to the staging area, commit staged files, pull changes from remote repositories, push your changes to remote repositories, and submit pull requests. If you get stuck, or get some weird error message, usually you can Google the message and read forum posts or Stack Overflow answers, as other people have likely encountered the exact same issue before. Some good Git resources include:

For the steps on setting up a development environment for the HTML5 client, see: ***Under construction: write something here!!***

For the steps on setting up a development environment for the mobile client, see: ***Under construction: write something here!!***

As of September 2014, the most important component of BigBlueButton that has yet to be implemented is the video module for the HTML5 client. This is because there is no suitable WebRTC live video streaming server that BigBlueButton can use. The way the Flash client does this, is by capturing webcam media, encoding it in H.264, and streaming it to BigBlueButton-Video using the RTMP protocol. BigBlueButton-video is Flash based, and can handle the re-streaming of this video stream to the other Flash clients. The HTML5 client does not use Flash, but instead uses WebRTC to capture and stream media. The philosophy of WebRTC is to use completely open and non-proprietary codecs and protocols, and both the RTMP protocol, and the H.264 video codec are proprietary. The most widely used WebRTC video codec is VP8. What BigBlueButton needs is something that can re-stream this video stream to all HTML5 clients, and something that can transcode between VP8 and H.264 so that the different clients (HTML5 and Flash based) can share video between them.

BigBlueButton at Seneca CDOT

Current Projects

HTML5 Client

With mobile devices dropping Flash support, and HTML5 rising to replace Flash on the web, we are looking into adapting BigBlueButton to an HTML5 and JavaScript application. The first step in this is to develop an HTML5 client that can participate in an existing meeting (where the presenter is using the Flash client) at the most basic level. As of autumn 2014, the only core component missing is the video module. This is because, as of yet, there is no suitable WebRTC based video streaming media server (see above for more details).

In the summer of 2016, Danny Perrone, Matthew Marangoni, Laily Ajellu, Oleksandr Zhurbenko, and Jaeeun Cho, students from Seneca, along with with Anton Georgiev, a co-op student from Carleton university working at Blindside Networks in Ottawa, rewrote the existing HTML5 client, moving it over to the Meteor.js framework.

***WRITE STUFF HERE!!!***

HTML5 Client and React

React is an MVC framework for Javacsript that seamlessly and quickly updates your web app as soon as a change is made to it.

How? It "diffs the return value from the previous call to render with the new one, and generates a minimal set of changes to be applied to the DOM".

Developing the Mobile Client

The BigBlueButton mobile client is a mobile application that allows users to participate in a BigBlueButton meeting from their smartphone or tablet. It was started in late 2013 by a team of software developers from Mconf. Beginning in early 2014, the mobile project was taken over by a team of developers at Seneca CDOT. Chad Pilkey, Gary Deng, Stanislav Yeshchenko, and Adam Sharpe each worked on implementing features, rewriting components, and fixing bugs in the mobile client. In the summer of 2014, we:

Unit Testing the Mobile Client

With the mobile client's development coming close to completion, the importance of unit testing is becoming increasingly important. Though not in the spirit of test driven development, the unit tests are being written after the core application. See the following link for general information about unit testing, specific information regarding the framework we are using to unit test the mobile client, and information about the current state of the coverage of the unit tests.