On Demand Classrooms and Meetings

Our approach to BigBlueButton meetings


With a standard installation of BigBlueButton, you pass the instance URL and a secret token to a library or integration (such as Moodle) – which then communicates with the BigBlueButton instance to create and remove meetings, add users, manage recordings and so on.

BBB On Demand works just the same.

We provide you with a URL and secret token to use with your library or integration. All libraries or integrations that work with a standard BigBlueButton installation should work with BBB On Demand out of the box.

Conceptually, our approach is a similar to Scalelite; a BigBlueButton proxy that exposes a fleet of BigBlueButton servers via a single BigBlueButton API compatible endpoint. The benefit of BBB On Demand over Scalelite is that you don't need Scalelite, we manage the servers, you never run out of capacity and you are not paying for idle instances!

Our API endpoint ‘appears’ to your library or integration as a single BigBlueButton server through which you can create an unlimited number of meetings and manage an unlimited number of recordings. This is truly BigBlueButton solved!

On demand BigBlueButton instances with bbbondemand.com

Resilience and Performance

Our API, recordings servers and website are globally distributed, load balanced and auto-scaling. Requests will almost always be handled by a server in your part of the world and higher demand just means more servers will be added behind the load balancer.

  • Our global fleet of Stun / Turn servers provides redundancy and can be scaled with a single mouse click.
  • By moving the processing of recordings off the server we leave more resources available for the meetings - ensuring consistent and high quality video and audio.

A request to create a new meeting will take from roughly five to twenty seconds. Most other API requests will return in under a second, though some data intensive requests (such as listing large numbers of recordings) may take up to five seconds. Existing ‘keep alive’ settings will usually work unchanged but 30 seconds will be more reliable than the commonly used 20 seconds.

We place your meetings on virtual computers sized according to the settings passed to the ‘create meeting’ method. Meetings with settings suggesting a lighter load (with few participants and limits on webcam usage) may run on machines with 4 CPU and 16GB Ram. Large meetings will always be on high performance machines with at least 8CPU and 32GB of Ram. In all cases, we monitor the load on shared machines and manage usage so that all users have high quality meetings.

Managing Costs

Our service is cost effective because you only pay for what you use and you avoid the resource management inefficiencies that come with seat or instance based licensing.

We charge an hourly rate for meetings, billed to the nearest minute. The hourly rate varies depending on the resources that your meeting is expected to use based on the settings passed to the ‘create meeting’ API method.

  • The most important factor is the maximum number of participants, so you can save money by setting maxParticipants to a sensible figure. For example, if a school has a typical class size of 25, it might set this to 30 – to allow space for the teacher and for students who leave and immediately re-enter the room.
  • The Record, AutoStartRecording and AllowStartStopRecording settings also increase the cost of the meeting.
  • On the other hand, LockSettingsDisableWebCam, WebcamsOnlyForModerator, and LockSettingsDisableMic all reduce meeting cost because they are predictive of lower server load.

To make the most cost effective use of BBB On Demand, configure your library or integration to use the settings you actually need. We provide a Pricing Calculator so you can check the actual cost of a meeting depending on the configuration passed to 'create meeting'.

On the account page, there are two additional settings to help you to limit your costs.

Maximum Duration puts a ceiling on how long meetings can run if the 'duration' parameter to the create meeting method is not set.

  • For example, if Maximum Duration is set to 200 on account page and the meeting is created without the 'duration' parameter (or if it is zero) then the meeting will automatically end after 200 minutes. Note that the meeting will not provide the 'remaining time' countdown at the top - and there will be no warning that the meeting is about to end: it just ends.
  • This setting is intended to avoid the risks of users accidentally leaving meetings open which would rack up high costs. It is recommended that you set this to 2 or three times your normal meeting length and use the duration setting if you need a longer meeting (which overrides Max Duration).

Maximum Participants puts a ceiling on the number of participants in any meeting if the 'maxParticipants' is not set (or is set to zero - which means unlimited) in the create meeting request.

  • For example, you set Maximum Duration to 50 on the account page and "maxParticipants" is not set in the create meeting request. The meeting will use the default ceiling and create the meeting with 'maxParticipants=50'.
  • You can override the account Maximum Duration setting with the maxDuration parameter to the meeting create method up to the BBB On Demand maximum of 155 participants.

Changes to the API

All or almost all libraries and integrations should work out of the box, but if you roll your own integration it is worth being aware of the places we have departed from the BigBlueButton API specification. If these cause any problems, or you spot any other compatibility issues, please let us know:

  • We are currently serving the 2.5.x branch of BigBlueButton - so do not support API methods relating to the now discontinued Flash based client. Methods such as getDefaultConfigXML and setConfigXML are ignored.
  • There is a hard limit of 155 participants for on demand meetings, setting maxParticipants to greater that will not result in an error but it will be re-set to 155
  • The new (in 2.5) insertDocument method is not yet supported but will be available soon.
  • We do not currently support the getRecordingTextTracks and putRecordingTextTrack but will add if there is any demand.
  • The BigBlueButton API documentation is not entirely consistent in how it returns error messages, with some but not all methods returning the fields ‘message’ and ‘messageKey’. We add these fields even when not mentioned in the BigBlueButton API specification because this made our own proxy more robust.
  • The contents of 'message' and 'messageKey' returned with errors might not match those from BigBlueButton; if any of these cause you problems please let us know, it is an easy fix.
  • We do not currently support the optional WebHooks API but plan on adding this in the near future.
  • With standard BigBlueButton, no information is returned about a recording until it has finished processing - and by default it is immediately published. With BBB On Demand, the API returns information about the recording whilst it is being processed: "state" is shown as 'processing' - and when processed the state is 'unpublished'. It is then up to you whether to publish this recording. Trying to publish a recording that is still in 'processing' state returns an error. So far, we have found this behaviour to work very well with integrations.
  • Attendee data is removed from the getMeeting and getMeetings record and not stored on our systems to ease GDPR compliance. Please get in touch if this causes problems as we may consider making this configurable.

BigBlueButton upgrades and configuration

  • We typically upgrade BigBlueButton every two months, working from a fresh install.
  • When there is a 'major' release (eg. from 2.4 -> 2.5 -> 2 .6) We typically wait three months before moving to the major release to allow any major problems to surface and be fixed.
  • We use the standard version of BigBlueButton with some well known optimizations, such as dynamic video profiles, video pagination, parallel Kurento and disabling the old flash client.
  • We support the options under the BigBlueButton documentation section: "Passing Custom Parameters to the client on join".
  • We support playback of recordings on IOS devices, as long as you select to encode recordings in Mp4 (or Mp4 and Webm) in the Account page, Options tab.
  • At present, our servers and BBB installations are not configured to use IPv6, which might under some circumstances cause issues on IOS devices.

Turn / Stun servers

Turn servers are required by BigBlueButton when a web browser has difficulty opening the required ports for streaming video from the BigBlueButton server. We maintain a globally dispersed fleet of correctly configured Stun / Turn servers – and request to join meetings are adjusted to use the Turn server closest to the meeting and an additional one for redundancy.

This increases the proportion of your meeting participants who will be able to successfully join and participate in conferences. It also means that you do not become embroiled in the dark arts of stun and turn!

Managed Recordings

One of the challenges of BigBlueButton at scale is how to handle recordings, which end up strewn across multiple servers. We solve this problem through BigBlueButton Managed Recordings.

Meetings are recorded in the usual way, but when the meeting finishes, recording data is moved to a separate high performance server for immediate and high speed processing. The processed recording is then moved to long term cloud storage. If published, it is then hosted for viewing directly from our servers.

Our Managed Recordings infrastructure solves whole classes of headaches, costs and risks associated with a rollout of BigBlueButton.

Learn more about the advantages of Managed Recordings.