The idea is to run a loadbalancer node which maps each BBB node to a
path. That way each user gets only one gUM permission query for a
cluster. The loadbalancer node only serves the html5 client, each BBB
node will serve its own API and handle the websockets for freeswitch and
bbb-webrtc-sfu.
Configuring a cluster setup
===========================
* let bbb-lb.example.com be the loadbalancer node
* let bbb-01.eaxmple.com be a BBB node
Loadbalancer
------------
On the loadbalancer node add an nginx configuration similar to this one
for each BBB node:
```
location /bbb-01/html5client/ {
proxy_pass https://bbb-01.example.com/bbb-01/html5client/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
```
BBB Node
--------
On the BBB node add the following options to
`/etc/bigbluebutton/bbb-web.properties`:
```
defaultHTML5ClientUrl=https://bbb-lb.example.com/bbb-01/html5client/join
presentationBaseURL=https://bbb-01.example.com/bigbluebutton/presentation
accessControlAllowOrigin=https://bbb-lb.example.com
```
Add the following options to `/etc/bigbluebutton/bbb-html5.yml`:
```
public:
app:
basename: '/bbb-01/html5client'
bbbWebBase: 'https://bbb-01.eaxmple.com/bigbluebutton'
learningDashboardBase: 'https://bbb-01.eaxmple.com/learning-dashboard'
media:
stunTurnServersFetchAddress: 'https://bbb-01.eaxmple.com/bigbluebutton/api/stuns'
sip_ws_host: 'bbb-01.eaxmple.com'
presentation:
uploadEndpoint: 'https://bbb-01.eaxmple.com/bigbluebutton/presentation/upload'
```
Create the following unit file overrides:
* `/etc/systemd/system/bbb-html5-frontend@.service.d/cluster.conf`
* `/etc/systemd/system/bbb-html5-backend@.service.d/cluster.conf`
with the following content:
```
[Service]
Environment=ROOT_URL=https://127.0.0.1/bbb-01/html5client
```
Change the nginx `$bbb_loadbalancer_node` variable to the name of the
load balancer node in `/etc/bigbluebutton/nginx/loadbalancer.nginx` to
allow CORS requests:
```
set $bbb_loadbalancer_node https://bbb-lb.example.com
```
Prepend the mount point of bbb-html5 in all location sections except
from the `location @html5client` section in
`/etc/bigbluebutton/nginx/bbb-html5.nginx`
```
location @html5client {
...
}
location /bbb-01/html5client/locales {
...
}
```
Previously we were using the same for listenonly, which for default
environments points to kurento, and didn't make any difference in media server
selection.
This could be problematic in those environments where meta param
for listeonly media server is set , though.
Fullaudio has now it's own meta param that can be passed through API:
"meta_media-server-fullaudio"
This commit allows user to join/leave audio using the fullaudio bridge.
This is still under development, but to use this now we must set values of
skipCheck to false, and defaultFullAudioBridge to fullaudio. This
depends on newest version of bbb-webrtc-sfu
ICE lite servers (eg mediasoup) dont need candidates signaled out-of-band; neither does KMS in certain scenarios
Disable their signaling saves us some ticks in bbb-webrtc-sfu and some bandwidth all around
Restored the old behavior when ending breakout rooms while user is in the
breakout audio transfer, which is to the trigger the reconnection to the audio
in the main room.
This behavior could be improved by (instead of reconnecting) transfering user
back to the main room, but this requires some changes in akka-apps/fsesl
which can be treated in a different issue.
Closes#13242
Applies to video, listen only and screen sharing
New metadata values: media-server-video, media-server-listenonly, media-server-screenshare; parameter is a String
We now let audio-manager log errors, using the specified error code.
These errors are still logged in bridge layer, but as a warning.
This commit doens't change error codes behavior, they are still being
logged as errors and with the same code numbers.
Here's what we do when user activates mic:
1 - When we do something similar to listenonly's joining process
until we find a valid candidate-pair. The information about this
local candidate is store.
2 - We then start a new userAgent, and as soon as browser finds
a candidate with the same local ip address, we leave only this
candidate in the SDP and send this to FreeSWITCH. SDP should
contain only a single candidate.
3 - The rest of signaling process is basically the same.
When joining breakout audio, the output device selected in the main room is
used in breakout.
When returning from breakout rooms, the output audio device previously set in
the main room is restored.
Some specific info:
SIPSession doesn't handle Storage anymore, we do this in SIPBridge, since
it has more info about the current selected device and it doesn't depend of
a session being oppened.
We also now pass the output device ID when joining audio sessions. We can
then keep this information in the Storage.
Closes#11663
This commit contains three fixes: one already reported and two detected
during the investigation of the solution.
This started as a fix for firefox (#12023), but i also fixed the muted
alert/banner when device changes: the banner wasn't detecting device changes,
unless audio was deactived/actived.
There's another fix for the microphone stream: we now keep sender's track
disabled if it was already disabled for the sender's track of the previous
selected device.
Also did small refactor for eslint checking.
Some technical information: in sip bridge (bridge/sip.js), setInputStream and
liveChangeInputDevice function were both fully turned into promises, which
guarantees we have everything ready when it resolves to the respective values.
This helps AudioManager (audio-manager/index.js) to sequentially sets and
tracks the state of the current microphone stream (inputStream), when calling
liveChangeInputDevice function: we first set the current stream to null,
creats a new one and then set it to the newly created value - this is needed
because MutedAlert (muted-alert/component.jsx) can then gracefully
allocate/deallocate the cloned stream when it is set to a non-null/null value
(the cloned stream is used for speech detection with hark).
In MutedAlert we also make sure to enable the cloned stream's audio
tracks, just in case the user change the device when muted (audio track is
disabled in this case), which also leaves the cloned stream muted (we then
enable the track to allow speech detection).
Closes#12023
Firefox doesn't create a device called 'default' and we were trying
to set this when user is joining the room. We don't do this anymore, letting
devices to be changed when there's some user request.
Moved outputDeviceId inputDeviceId information to be managed in bridge
(just like we do with inputDeviceId), we don't store this duplicated
information in audio container anymore.
Fixed the eslint warning in "playAlertSound(url) { ..."
We are safe to let users try to change input/output devices because the
device list is retrieved from enumerateDevices.
Allow listenonly users to change output devices
Fixed dynamic audio device change for firefox
Fixed shortcuts for audio join/leave
Show (with a bold font) the current selected device
[performance] Prevent calling mediaDevices.enumerateDevices every time we render
the selector. This adds a delay (~200ms, on my chrome setup) to render this component
[performance] Do not call enumerateDevices to search for new devices, instead we listen on mediaDevices.deviceChange event
Small refactoring and fixed a few errors that were being throw in browser's console
Fixed device selection when this is done in audio-settings modal
Fallback to default device when current device is removed
Truncate device name length
Renamed "Input","Output" labels to "Microphone","Speakers", respectively
Update eslint rule for accessKey
Without 'exact' match, the browser fallbacks to the default inputDeviceId
This prevents the error (input device error) when breakout is ended and we try
to skipCheck the microphone when user returns to main room (assuming the
user had the microphone active before joining breakout room).
Without 'exact' match, the browser fallbacks to the default inputDeviceId
This prevents the error (input device error) when breakout is ended and we try
to skipCheck the microphone when user returns to main room (assuming the
user had the microphone active before joining breakout room). Related
to the feature c451666d52
As explained in #11143, disabling audio filters is desired in some scenarios.
This basically adds an option for user to disable default constraints.
When user doesn't change this value in Settings > Application, the default
value for each audio constraints is retrieved from settings.yml.
When user changes this value in Settings > Application, audio
filters (AGC, Noise Supression and Echo Cancellation) are all set to
true/false, according to the value selected in the Settings GUI.
To start it simple, we decided to not to add a different setting in the GUI for
each audio contraint. This may be added in the future, though (perhaps in a
dedicated Audio Settings tab)
This is related to #4873
As explained in #11143, disabling audio filters is desired in some scenarios.
This basically adds an option for user to disable default constraints.
When user doesn't change this value in Settings > Application, the default
value for each audio constraints is retrieved from settings.yml.
When user changes this value in Settings > Application, audio
filters (AGC, Noise Supression and Echo Cancellation) are all set to
true/false, according to the value selected in the Settings GUI.
To start it simple, we decided to not to add a different setting in the GUI for
each audio contraint. This may be added in the future, though (perhaps in a
dedicated Audio Settings tab)
This is related to #4873
In some scenarios, there's no need for the browser to apply such audio filters. For example, when user's microphone already does audio filtering (echo cancellation, noise supression ...).
This commit doens't change the current behavior (filters still follow browser's default config): admins need to uncomment/set these values if disabling/enabling specific filters if desired.
This is related to #4873
Audio client logs already cover audio session progress the way we need.
This avoids keepAlive and other unnecessary messages to be logged in browser's console.
If setting is not present, default value is set to false.
This was added as an option (websocketKeepAliveInterval), which is the interval to send keep alive messages.
Setting websocketKeepAliveInterval to 0 disables the keep alive, producing the same old behavior.
This helps avoid websocket disconnection due to socket inactivity, preventing it to unnecessarily reconnect.
Also, sometimes reconnect fails and error 1005 is triggered.
Fixes problems reported in #10985.
Also reduces occurrences of error 1005.
Fixed listen only reconnection handling
Added proper error handling; now all errors have proper mapped codes which are funneled through to audio-manager logger and should be easier to gauge types of errors
Fixed botched reconnection error rejection, audio modal shouldnt be stuck anymore when it fails
Remove every tie that listen only bridge had to kurento-extension
Instead of sending using rfc4733 standard, we use INFO message for all transfers
INFO message was used in older SIP.js version. Although this is not a standard for sending DTMF tones, this has more reliability (once it sent over TCP)
This might reduce occurrences of 1008
This is the same behavior we used to have on older sip.js version code
By doing this we reduce errors when user try to perform join/hangup during an websocket reconnection
This happens because FreeSWITCH is not able to parse the "From" header when it has multiple occurrences of ':'. So user is not able to join audio.
To fix, we now changed the "callerId" to use the base64 value of the user name, instead of directly using user's input (the callerId format keeps being a triple like this: <user_id>-bbbID-<base64_encoded_name>).
Once this callerIdName is encoded at the same point it is generated, there shouldn't be server side effects for changing this value; except for those places where the callerName is retrieved by splitting this triple (such as the voice talking-indicator, as described below).
Updated the talking-indicator to retrieve the username from User's object, instead of retrieving from the one username generated by splitting the callerId triple.
This problem also happens in versions <= 2.2.26.
This adds the possibility to configure the SIP Via header to plain WS to allow reverse proxying from WSS to WS, internally, to work around a bug in freeswitch where the WSS stack would get deadlocked due to a still unidentified bug in there that has to do with SSL termination
Although Chrome's default is now unified plan, Chrome <-> FreeSWITCH ICE connection fails for some Chrome installations (specially those running on Windows).
FS ICE fails when Chromes's SDP has "a=mid:<index>" (instead of "a=mid:audio").
This fixes Error 1010 and situations where echo test takes too long.
This fixes#6414 regression, once we do the same older version of SIP.js used to do.
We now use both peer's connectionstatechange and iceconnectionstatechange to monitor ICE state for audio sessions.
The same way we did with old sip.js version, we leave iceconnectionstate trigger audio actions , such as connect, disconnect, reconnect.
We still listen for 'failed' state for connectionstatechange event, because chrome triggers this (tested on 86+).
This should reduce the audio error 1010 ocurrences, once some browsers (specially Chrome/Android) don't trigger connectionstatechangeevent.
This might reduce problems reported in #10708, which still needs more investigation though.
Maps WebSocket's 1006 error to BBB's 1002, the same way it was done with old sip.js version
Set user agent's number of reconnection attempts to the same value as older sip.js version
Changed the maximum attempts of the UserAgent reconnection (this should be changed when binding audio's websocket to meteor's connection state).
Added a log to monitor WS reconnect attempts.
When closing/reloading tab with active microphone, audio exits successfully but a wrong log-error (1005) is shown.
We now process closing/reloading tab the same way we do when user hangup the call.
For some reason (still investigating), using turn/coturn on 443/tcp makes firefox's iceGathering process (during echo test) takes 12+ seconds (tested on webrtc's trickle page with multiple instances).
This was found when testing the current default (15s) on production with a private turn/coturn server on port 443/tcp. For default bbb setup (stun only), echo test still runs fast.
To avoid adding extra delay to iceGathering on this scenario (Firefox + turn on 443/tcp), i am just setting the default value back to the 5s (old default).
So , for those who wants to reduce the 1004 occurrences, increasing the iceGatheringTimeout could help (just be aware this adds delay on the mentioned scenario).
Added a default 'MEDIA' option: iceGatheringTimeout. This option allows admin to set a higher ICE gathering timeout, which can help when getting ICE errors during audio negotiation (eg 1004)
Default value set to 15s (current default is 5s).
Sometimes, when user already joined audio session, RTCPeerConnection may
find new ICE candidates, which triggers 'connected' state for peer's
'onconnectionstatechange' event. When this happens we process this
new state the same way when user is not running an audio session, which
makes html5client popup an annoying 'Audio Connected' message.
The audio keeps working fine, but this can make user think that there's a
connection issue, or the audio is reconnecting, while audio is ok.
When getting disconnected with 1001 ("websocket closed unexpectedly" error) we were creating a new SIP session, therefore a new FreeSWITCH channel.
While reconnecting the socket, instead of closing the SIP session, we keep it alive during reconnection (audio should keep working in the meantime). When reconnected we keep using this same session (avoiding the creation of an extra one).
We also better handle WebSocket error codes from SIP.js.
FF immediately closes websocket when unloading page, so we now to stop user agent when 'beforeunload' event is triggered, to avoid leaving open sessions in FreeSWITCH when user leaves page.
When refusing ("thumbs down" button) echo test, user is able to select a different input device. This should work fine for chrome, firefox and safari (once user grants permission when asked by html5client).
For output devices, we depend on setSinkId function, which is enabled by default on current chrome release (2020) but not in Firefox (user needs to enable "setSinkId in about:config page). This implementation is listed as (?) in MDN.
In other words, output device selection should work out of the box for chrome, only.
When selecting an outputDevice, all alert sounds (hangup, screenshare , polling, etc) also goes to the same output device.
This solves #10592
This considerably changes the way we process audio signaling and start audio elements in user's browser.
We now avoid using AudioContext element for both microphone and listenonly calls, once it is unstable for some iOS devices (cracky audio, user stops hearing audio after a while).
Increased default value for listenOnlyCallTimeout: this avoids activating FreeSWITCH's fallback when ICE negotiation takes longer than 15sec (tested on DO).
Increased listenonly logs.
This fixes#8133#10388
Refactored STUN/TURN fetch to be done only once, when successful, per session and cache it in mem to avoid too many reqs. Current way is a bit dumb, this should increase reliability a bit more. The caching is configurable so folks who want to use very short lived TURN credentials can disable it
Add a fallback STUN config option to be used when the default STUN/TURN fetch fails
Clean the safari/no candidate generation pre flight check from 3rd party STUNs
Fix deadlock in audio join when STUN/TURN fetch failed
