Conference room

_images/conference_room_concept_plain.png

A conference room is a logic entity composed of a audio room and a video room, tied together and managed from a signalling service and under a number of configuration parameters. The audio room is created in a multi conferece unit (MCU) implemented in a Quobis wac service named audiomixer, while the video room lives in a singe forwarding unit (SFU) implemented in Quobis wac in a service called the video SFU. Both rooms are “coordinated” by the QSS and other internal services in order to provide a complete audio and video experience to the end-users.

Note

Summary: a Please pay to attention to the difference between a “audio room” or a “video room” with a “conference room” (which is a combination of a audio room, a video room and a set of parameters).

Every audio or video connection made with Quobis wac is managed via these three internal components, regardless of the number of users and thus providing the same set of functionalities. This conference-centric approach with support to call-oriented scenarios is one of the key benefits of the platform and eases the design and implementation of a wide range of use cases thanks to its flexibility.

Audio MCU

Quobis WAC provides an audio MCU (usually refered to as “audiomixer”) based in the Asterisk open source software. The role of the audio MCU is to join together all the audio streams from the participants (both WebRTC and SIP ones) into a single mixed stream that is provided back to all the participants, by making use of the “confbridge” functionality. It is also responsible for the audio recording and interconnection to the SIP network.

Video SFU

Quobis WAC provides a SFU based in the Janus open source software. The role of the video SFU is to dispatch video stream to the conference participants, and it’s also responsible for the video recording. The Quobis WAC -in fact, the QSS- takes care of the setup of an audio MCU room and a video SFU room that are tied together in order to setup a conference room. There is a 1-to-1 relationship between the video SFU room and the confbridge instance within the audio MCU. All the SIP calls which can be introduced in the SFU room will also join this same confbridge.

Note

The developers using the SDK will not need to deal with these details as the audio/video room management is perfectly wrapped by the SDK code.

Properties

A conference room has a set of properties that configure its behaviour and what can be done. Some of these functionalities affect the whole platform while others can be applied to individual conferences.

  • Access Control List (ACL): this list indicates the user(s) that can access a conference room and that are allowed to publish/subscribe media into it. It is basically a list containing a map of the user ID and a temporary token that it’s used internally to create the conference room. There is no limit on the maximum number of users in a ACL and it cannot be changed right from the client application (it’s up to the QSS to do that on behalf of the client). On the other hand, there are a number of events that notify the client application about changes in the ACL (see section “Conference room events” for a detailed list).

  • Room ownwership: a system-wide parameter (setOwner) controls wether conference rooms can have an owner or not.If this parameter is set, the parameter updateRoomWhenOwnerLeaves needs to be taken into account as well: if set to true, a new owner is chosen from the available users in the conference room when the current owner of the conference room leaves it. Both parameters are set in the QSS.rooms service.

  • Maximum number of participants: accounts for the maximum number of simultaneous participants into a conference room (regardless of which ones of them are publishing audio streams, video streams or both). Defaults to eight (8) users in case no value for provided in the configuration file (parameter participantsLimit). Please note that this is a system-wide parameter so it can not be changed for each conference room. When a client application tries to add a participant and this limit has been reached, an error is thrown. This parameter is set in the QSS.invites service.

  • Allowed audio and video codecs: list of allowed codecs in the conference room. There can be several codecs, but only one can be used at the same time. Please note that this is a system-wide parameter so it can not be changed for each conference room. If no codecs are provided, default ones are Opus for audio and VP8 for video.

  • Bitrate: this parameter, measured in Kbps, defines which is the maximum allowable bitrate per user including every both audio and video streams. The system will prevent the client application to deliver more bandwidth that the one specified in this parameter. This parameter is configurable as explained here.

  • Recording capabilities: this parameter is configurable for each conference room and can be set to audio only, video only, both or none. More details about how recording works and its implications can be found in the recording section.