100% translated for the source file 'bigbluebutton-html5/public/locales/en.json'
on the 'fr' language.
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
100% translated for the source file 'bigbluebutton-html5/public/locales/en.json'
on the 'hu_HU' language.
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
Audio state callback and remote media setup both depend on FS's state
(comes through Meteor) and the ICE state (local, peer connection). The
caveat: FS's state can come delayed on reconnection scenarios because
Meteor's websocket generally takes significantly longer to re-connect than
the peer connection, which means the ICE state gets completed way before FS
is flagged as ready.
The practical issue: while outbound audio (client -> FS) will work, inbound
audio (FS -> client) won't _just because it wasn't played_ (even though
data is coming through).
This commit decouples the remote media setup step from the state
through:
- Setup remote media when ICE state is completed
- Run the state callback only after FS is flagged as ready. This
should maintain the UI states consistent across client-server.
Keep in mind the assumption that if FS is ready, ICE is completed by
consequence.
The voice user ejection callback tethered to Meteor's socket
disconnection seems broken (since its introduction). The VU selector
uses an invalid field (requesterUserId) - so no VU is ever returned.
Since I'm unaware of the original goal behind this code and there's
already ejections in place in other components (akka-apps, for
instance), this is basically a revert of #9888.
There are some issues with the way FreeSWITCH changes candidate pairs
based on connectivity checks. That generally manifests as: 1) an asymmetric
start time between inbound and outbound audio (eg inbound audio takes 20
seconds to come in while outbound works right out of the bat
2) wrong pairs being picked initially and FS taking longer
than ideal to find a new one 3) 1006s, 4) ....
This backports signalwire PR 1914 in an attempt to mitigate
the aforementioned issues. The PR description explains the rationale
rather well and seems sound. I've tested this in demo servers with midly
satisfying results, but still needs further testing.
100% translated for the source file 'bigbluebutton-html5/public/locales/en.json'
on the 'tr' language.
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
There's a scenario where remote streams won't be attached again if the
sharer experienced a Meteor/client disconnection.
The disconnection empties some necessary user data temporarily, which
causes the corresponding video-list-item to be unmounted while the peer
persists for a little longer.
If the sharer re-connects fast enough, video-list-item will re-mount but
will 1) miss the current stream state (ie stuck in loading) 2) fail to
re-attach the streams since the peer was already flagged as attached.
Ensure remote camera streams are always attached and shown by:
- always propagating the current stream state on attachment
- refactoring the attachment pre-requisites away from a static boolean
to a required data + diff check (based on target and current
attached streams)
