In Chrome, if 'maxBitratesVideo' options are specified
and 'capScreenshareBitrate' is disabled, then simulcast is enabled
for screenshare. Chrome in plan B, does not send screen stream if
'maxBitrate' are set and simulcast is enabled.
Device IDs can change without triggering any event. In order to sync the
device IDs that we store with the actual device IDs, we need to update
them every time when we call enumerate devices.
fix(audio-levels): Reset audio level to 0 when remote user is muted.
When using getSynchornizationSources on the audio receiver to gather audio levels for remote tracks, browser reports last known audio levels even when the remote user is audio muted, we need to reset the value to zero here so that the audio levels are cleared.
fix(safari): Remove old remote tracks when a new track is received for an endpoint.
On Safari, MediaStream.onremovetrack is not fired when a remote desciption with a removed MSID is applied. As a result, new remote tracks for the same endpoint are not created causing issues where the video is not updated on Safari. Also, make sure local tracks on pc are updated when devices are changed while the user is in muted state.
Both of the cases where user clicks cancel and when screen recording
permissions were not granted at the OS level are almost the same,
except for a small difference in the error.message.
This was only tested on Chrome 85.0.4183.121/Mac OS 10.15.6
feat: Adds a method that finds the SSRC of a JitsiTrack (#1338)
Adds a JitsiConference.getSsrcByTrack() method that finds the SSRC of a JitsiTrack by its SSRC. This method is currently used to get (and display) the first audio/video SSRC in the GSM popover in Jitsi Meet.
Co-authored-by: George Politis <gp@jitsi.org>
Since we use transferable streams to transfer the streams to the worker
we need to feature detect them as Chrome 86 will launch Insertable Streams
by default without shipping transferable streams yet (status still unclear,
it might still ship too)
See here for the feature detection used:
https://groups.google.com/a/chromium.org/g/blink-dev/c/1LStSgBt6AM/m/hj0odB8pCAAJ
This the second stage in our E2EE journey.
Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.
This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.
Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.
Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.
feat: Allows jvb to control DTLS/SRTP protection profile. (#1300)
We're pretty sure it's no longer necessary with JVB2; and it costs
half an RTT in setup, and stops us being able to choose which
DTLS/SRTP protection profile to use.