Technical

Guest feature

The “guest” feature was added to Mconf-Live at the end of the last year and it adds an important feature to the system: it allows a moderator to control who can access the meeting from within a meeting.

When a guest user wants to join in the meeting he will need that a user with moderator privileges approve his entrance. If a meeting has more than one moderator, a guest pop-up window will appear in the top right side asking if you allow the new user to enter in the meeting. If there isn”t a moderator in the meeting, the system stores the list of users that are waiting permission to enter and show it as soon as a moderator joins.

The picture below is the moderator view when a guest tries to join:


The moderator can allow a user to enter clicking on the green button or deny his access by clicking on the red button. He can allow all the guests that are waiting clicking on “allow everyone” or deny them clicking on “deny everyone”.  He can also check the “remember” option, meaning that the same action casino online will be taken for the next users that try to join the meeting (useful to allow or deny everyone from now on).

You can change the default option that you chose clicking in the setting button.

The picture below shows the guest waiting screen:


The picture below shows the message that appear when the moderator denied access to the guest:

Implementation details:

Without the guest feature, it”s the web application (or integration as usually called) that decides if a user has permissions to join a meeting. In Mconf this is done by Mconf-Web. With online casino the guest feature this is still valid, but now the web application can also tell the web conference server that the user can join the meeting but only after being explicitly accepted by a moderator.

The implementation of the guest feature was done by adding a new parameter to the “join” API call. This parameter is called “guest” and is optional. If present and set to “true”, the user joining the conference will be treated as a guest. If not present, the API will behave as it does today (i.e. the password will define if the user is a moderator or an attendee).

The passwords in the “join” API call are still used to define the role of the user, even if he is set as a guest. So if the API call has the moderator password and the parameter guest set, the user will “pre-join” the meeting, wait for a moderator to approve his entrance, and when he finally joins he will be a moderator (i.e. even moderators have to be approved when they are set as guests).

In Mconf-Web (and so in mconf.org) now only moderators will automatically join a meeting without being a guest. If a user is a normal attendee, he will be set as guest.

You can read more details about the changes in the API at our wiki: https://code.google.com/p/mconf/wiki/MconfLiveApiChanges#Join_Meeting

By |March 26th, 2013|API, BigBlueButton, Mconf-Live, Technical|Comments Off

Mconf-Live 0.3

We are glad to announce a new version of Mconf-Live, which introduces two new features:

  • A new kind of participant that can only visualize the conference (but not transmit audio or video);
  • A first version of the network monitor.

On the previous version when a user wanted to hear the conference, he was forced to enable his microphone as well. In addition, when the user enables his microphone, the system creates a stream that goes from the client to the server, even if he doesn”t want to talk, just listen. The problem is that every new audio stream creates a server-side overhead, because FreeSWITCH (that handles all the audio processing) generates an outcoming stream for each incoming stream. Each outcoming stream is formed by all the incoming streams except the correspondent incoming stream. The independence among outcoming streams makes it possible to send audio messages to a specific user, such as “You are now muted”.

The audio architecture was designed for high interactive sessions, but it doesn”t fit well on sessions with a low number of interactions but with many users, such as webinars. In theory the current architecture can handle a large number of participants (depending on the hardware), but often you will notice audio artifacts on the session, which are generated during the mixing process.

With this scenario in mind we proposed a simple architectural modification. When the user joins a session, he will receive an audio stream that is the result of all the other users streams mixed – this audio stream is called global stream, or global audio. Only when the user wants to talk that he will click on the headset icon and then join the session as a speaker. Internally the user will leave the global audio and create two new streams, an incoming stream and an outcoming stream, just like it was on the previous architecture.

The modification proposed (and implemented on Mconf-Live 0.3) aims to make the system more scalable and to increase the audio quality. The scalability improvement is due to the removal of the overhead that was generated during the mixing process. In the new architecture, the FreeSWITCH server will mix a smaller number of streams, and it will reduce the processing power needed for it. The audio quality improvement is justified by the same reason: mixing a online casino smaller number of streams will reduce the probability of annoying artifacts.

A side-effect of the proposed architecture is that the user is able to open an incoming stream without opening an outcoming stream. It will reduce by 50% the bandwith requirement to listen an audio session, making the system more friendly to low bandwidth connections.

The UI will remain almost the same, except by two aspects. First, the “Listeners” window now will show the users with the microphone activated, so it will be a “Speakers” window. Last, we added a new button on the toolbar that mutes or unmutes the user”s speakers (see the figure below). Since the user will join the session and start listening automatically with no action required, we had to create a mechanism to mute this audio. The effect of this button is local only – the other users will continue listening normally.

New button on toolbar

We are introducing also on Mconf-Live 0.3 a network monitor. The ability to watch how much bandwidth is being consumed by the system and the latency between the client and the server may help users to identify the reasons for a low quality experience. The bandwidth data is presented at the bottom of the screen and is updated each couple of seconds, and if the user places his mouse over the data, a more detailed window is presented with the bandwidth consumption and latency. This is a preliminary development, and it should evolve on next iterations.

Network monitor accessible through the bottom bar

A test server was set up for the users to test the new version before the final deployment to the Mconf Network, it”s available on http://lab1.mconf.org and the source code is available on GitHub. Any feedback is appreciated, hope you enjoy it!

By |January 11th, 2013|Mconf-Live, News, Technical|Comments Off