This is an initial, experimental implementation of the feature proposed in
https://github.com/bigbluebutton/bigbluebutton/issues/14021.
The intention is to phase out the explicit listen only mode with two
overarching goals:
- Reduce UX friction and increase familiarity: the existence of a separate
listen only mode is a source of confusion for the majority of users
Reduce average server-side CPU usage while also making it possible for
having full audio-only meetings.
The proof-of-concept works based on the assumption that a "many
concurrent active talkers" scenario is both rare and not useful. With
that in mind, this including two server-side triggers:
- On microphone inactivity (currently mute action that is sustained for
4 seconds, configurable): FreeSWITCH channels are held (which translates
to much lower CPU usage, virtually 0%). Receiving channels are switched,
server side, to a listening mode (SFU, mediasoup).
* This required an extension to mediasoup two allow re-assigning producers
to already established consumers. No re-negotiation is done.
- On microphone activity (currently unmute action, immediate):
FreeSWITCH channels are unheld, listening mode is deactivated and the
mute state is updated accordingly (in this order).
This is *off by default*. It needs to be enabled in two places:
- `/etc/bigbluebutton/bbb-webrtc-sfu/production.yml` ->
`transparentListenOnly: true`
- End users:
* Server wide: `/etc/bigbluebutton/bbb-html5.yml` ->
`public.media.transparentListenOnly: true`
* Per user: `userdata-bbb_transparent_listen_only=true`
Now it`s called AudioFloorChanged* to properly reflect its role
Add fields to carry the floor state (boolean) along with the uID and vID to be able to send events for a floor takeover and a floor surrender
This change introduces a config file
`/etc/bigbluebutton/bbb-fsesl-akka.conf` which reads the default config
from packages and allows operators to keep their own config file changes
across package upgrades.
bbb-conf is adjusted to deal with this change.
The lack of handling to check whether the user was a dial-in user when answering akka-apps periodic member probes was making it use an arbitrary default (callerName) as the userId, explicitly violating the convention that dial-in/outs should have v_memberId userIds
That would botch whichever added janitorial tasks that operated upon akka-apps GetUsersStatusToVoiceConfSysMsg probes
We need to increase the length of the voice conference. If we have lots of meetings running,
there is a high chance of collision.
Need corresponding changes to FreeSWITCH dialplan.
In bbb_echo_test.xml, change to `expression="^echo(\d{5,11})$"`.
In bbb_conference.xml, change to `expression="^(\d{5,11})$"`.
The /healthz returns information is we are able to send and receive message to/from freeswitch.
The /status returns information about freeswitch version and uptime.
Currently, we user DTMF to inform the client when the call session is in echo test and when entering the voice conference.
Unfortunately, sometimes when FS sends the DTMF, FS crashes.
Monitor the progress of the call session using ESL events and propagate to the client.
The client would be informed of these call states: CALL_STARTED, IN_ECHO_TEST, IN_CONFERENCE, CALL_ENDED.
- When waiting for a response from FS after sending an ESL command and the ESL connection disconnects,
the sending thread will be blocked as the trigger for it to unblock is the response from FS which never
comes.
Add a 30 second timesout waiting for response and give up to go send a new FS ESL command.
- We had an issue where FreeSWITCH, for some unknow reason, stopped recording the voice conference
in the middle of the meeting while there are users in the voice conference. We've relied on the
voice conf started event to trigger recording of wav files. This event is sent when the first user
joins the voice conference. In this case, there was no voice user joined after the recording stopped
as there were already users in the voice conference. TO make sure that the audio is recorded, akka-apps
will send a "check if voice conf is running and recording" message to FreeSWITCH every 30sec. If akka-apps
receives a "running=true recording=false" response from FreeSWITCH, akka-apps will send a start recording
msg to FreeSWITCH.
- when meeting ends, we try to eject all users by force from freeswitch to make sure
that recording ends. However, we are not actually sending the command to freeswitch.
This change sends the command so that users can be kicked out.
- on auto-reconnect when FS restarts, the auto-reconnect add another
listener to the ESL client resulting in multiple handlers of ESL events
and multiple messages to akka-apps. This resulted in multiple recordings
of audio when the first user joins as akka-apps receives 2 user join events.
- FreeSWITCH core dumped and akka-fsesl managed to reconnect. However, commands (mute, unmute, record, etc.) to FS are not reaching FS.
But events (user joined, left, talking) from FS are received by akka-fsesl. Can't determine where the commands are falling off. These
extra logging hopefully helps us narrow down if this happens again.
I wasn't able to reproduce the issue when stopping and restarting FS. Akka-fsesl reconnects and command/events are flowing in both
directions.
