How It Works

Overview

BigbluebuttonRails has three entities: servers, rooms and recordings. Servers can have multiple rooms, that belong to a server and can also belong to any other model (a User, for example). Recordings belong to a room and to a server (the room doesn't need to belong to the same server).

Every server has an associated API object (using the gem bigbluebutton-api-ruby) used to access the BigBlueButton server. The controller for servers has mostly the standard CRUD actions defined by Rails.

The controller for rooms also have the CRUD actions, plus some specific actions to join, end, and check if a meeting is currently running in the room. These extra actions will be explained bellow.

A room model has methods to fetch and send information to the BBB server. They are simple API calls, but the methods prefixed with fetch_ check the response and store data from it, while the methods prefixed with send_ just make the API call. You can, for example, use fetch_meeting_info to get information about the meeting (will trigger the API call getMeetingInfo). The data parsed from the response will be stored in the model and can be accessed using it's attributes.

All methods in the models that trigger any API call are documented with "Triggers API call" and the API functions that are called. Be aware that they can throw a BigBlueButtonException.

For information about recordings, check How recordings work.

RoomsController

running and end

These are pretty simple actions. running returns a json indicating if the conference is running or not, while end ends the meeting.

join_mobile

This is an action that simply renders a view with a QR code and a link to join the conference from a mobile device. The link and the QR code point to links using the protocol “bigbluebutton://”, so it can be associated with a native mobile application that will open the conference (such as the Android client for BigBlueButton).

join, invite and auth

The actions used to redirect a user to join a room are join and invite, while auth is used by invite to authenticate the user. Basic differences:

• invite renders a view to ask for a user name and a password. It is used to enable anonymous users to join a room or to define the user role using the room password instead of the bigbluebutton_role method.
  • It first checks bigbluebutton_role to see if the current user already has a role in the target room.
    • In case it has (see controller_methods.rb for more info), redirects to join.
    • Otherwise:
      • If there is a user logged, uses bigbluebutton_user().name as the user name. Otherwise, ask the user to type a name.
  • join requires a logged user and uses bigbluebutton_role to get the role for this user
    • It redirects the user straight to the meeting if the join is successful.
    • In case there’s no role associated with the current user, falls back to invite to ask for a password.

Internally, they use the same algorithm:

• If the user is a moderator:
  • If the room is not created yet, creates it.
  • Redirects the user to the meeting as a moderator.
• If the user is not a moderator (a normal attendee):
  • If the meeting is running, redirects the user to the meeting as an attendee.
  • Otherwise:
    • join renders the join view, to wait for a moderator before joining the conference. The page will continuously pool the server to check if the meeting is running. When it starts, it redirects the user to the conference.
    • invite renders the invite view again and shows a warning informing that the meeting is not running. The user must re-submit the form to try again.