The message/event UserLeftVoiceConfToClientEvtMsg is used when user leaves mic and listenonly, but it only sets to false the 'voiceJoined' (which represents the <hasVoiceVoiceJoined> property in BBB's XML API.
We now also set to false the 'listeningOnly' (which represents the <isListeningOnly> property in BBB's XML API). Setting both to false is not a problem, once 'MIC' and 'ListenOnly' states are mutually exclusives
Fixes#10852
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.
When user joins audio and for some reason an error (such as 1001, 1002,...), happens, the user is not able to click "Mic" and "Listen Only Buttons"; except if the audio window is closed and oppened again.
This patch modifies `bbb-record` allowing the user `bigbluebutton` to
delete recordings. The user has all necessary access rights, meaning
that the deletion works without a problem and the check for root does
not protect anything. The users owns the data after all. The current
check just makes things less convenient.
Currently, `bbb-record` uses a bunch of different style for indentation,
sometimes tabs, sometimes to, three or four spaces and these are
sometimes mixed on a line by line basis, making it hard to read and to
get what's going on.
This is a simple patch making the style of `bbb-record` consistent by
using three spaces for indentation which seemed to be the most commonly
used type of indentation here.
Using this larger value helps reducing ocurrences 1005/1010 errors for Chrome, avoiding an openssl's error which interrupts the dtls handshake (Chrome triggers "DTLS timeout expired" error)
This key size is also the default value used by freeswitch on switch_core_cert.c
Fixed two occurrences where the tryGenerateIceCandidates workaround rejected without an error, which borked the callers error handling
Also put it behind a config flag. This workaround used to be important when Kurento didnt infer prflx candidates properly, but that`s no longer the case. With the flag, we can disable the workaround to see if there`s any visible regression and hopefully remove it down the road
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.
