WebRTC-based stats generation in the connection status modal is broken
on Firefox >= 125. A broken type check coupled with a new partially
implemented RTCIceTransport dictionary causes and undefined function
call when fetching the selected candidate pair. Since that error is
unhandled, collection breaks.
Correctly check for the getSelectedCandidatePair method availability in
RTCIceTransport so that it skips to pair inference from getStats if
necessary.
Audio exit toasts are fired in some redundant situations, e.g.: when the
error help screen is toast.
Change the logic a bit so that it's only fired when the audio help modal
won't be shown, i.e.: when audio had succesfully connected.
There are some situations where previously set deviceIds (
local/session storage) may become stale. This causes an unexpected
behavior where audio is temporarily borked until the user clears their
local storage.
This issue has been seen more recently on Safari endpoints when switching
back-and-forth breakout rooms in environments running under iframes.
Also seen randomly on endpoints with virtual input devices.
This centralizes audio gUM calling into a single method that retries the
gUM procedure without pre-set deviceIds only if the initial call fails
due with an OverconstrainedError - hopefully circumventing the issue.
Extract the deviceId again from the stream to guarantee consistency
between stream DID vs chosen DID. That's necessary in scenarios where,
eg, there's no default/pre-set deviceId ('') and the browser's
default device has been altered by the user (browser default != system's
default).
There's no rollback procedure in case a device switch fails right now,
nor does the code entrypoints that call the switching procedures wait
for resolution or failure before marking the new device as chosen. That
may cause inconsistent states in a couple of ways:
- No rollback: switch fails, audio is still on but no actual
microphone input is being transmitted
- Not waiting for resolutions: inconsistent chosen devices on failures
Device switching errors are also not surfaced to the end user
This commit:
- Adds device rollback and proper resolution/failure response
awaits to try and make the state a bit more consistent.
- Centralizes the input device switching code to be reused between
different bridges
- Centralizes device ID state management in audio-manager to try and
mantain them a bit more consistent across the board
- Surface device switching failures to the end user
- Guarantee device IDs are set to the session storage on all
appropriate scenarios
- Remove the old listen only bridge (kurento.js), superseded by the equivalent
and equally stable (AS FAR AS LISTEN ONLY IS CONCERNED) sfu-audio-bridge
- Rename FullAudioBridge.js -> sfu-audio-bridge.js
* A more generic name that better represents the capabilities and
the nature of the bridge
* The bridge name identifier in configuration is still the same
('fullaudio')
- Remove the FreeSWITCH listen only fallback
- Temporarily disable the "trickle ICE" pair gathering feature used
in SIP.js (which was always experimental, nonstandard and disabled
by default)
- Updates to settings.yml keys in places where relevant
"default" is not an universally valid default value for deviceIds which was causing issues with Firefox and Safari in some specific scenarios where exact deviceId constraints were being used
Seems to have been introduced by a partial merge commit
There were a bunch of style changes introduced by that partial commit as well; I kept those changes to avoid introducing further conflicts between v2.4-2.5...
When joining breakouts, we now wait for the bridge to be loaded before
automatically start user's audio.
This problems happens only on fullaudio bridge
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
For browsers that don't support headerBytesSent in RTCOutboundRtpStreamStats
neither headerBytesReceived in RTCInboundRtpStreamStats, we are now able
to calculate upload and download rates.
We are also able to get transportStats information for browsers that
don't support iceTransport attribute of RTCDtlsTransport.
Added support for getStats in screenshare's service. This works similar
to the getStats for video provider, and the information retrieved from
screenshare is added to the video information for cameras.
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.
