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.
