fix: Maybe start p2p only when we have received all presences.
There are cases where we start p2p on the first participant received presence, where there are more presences coming. This starts the process of p2p resulting and few iq errors while terminating it quickly after starting it.
On a normal joining as third participant we see around 38 send or received iq messages, in the problem scenario we see 60.
fix: Implement the encodings workaround only on Safari.
Explicitly check if all the encodings report the same scaleResolutionDownBy value before trying to ensure they match the expected values. This makes Chrome VP9 work again.
fix: Updates ping logic around detecting xmpp activity.
Now stores the time of the raw input when ping is received. Before this change we were storing the Date.now and comparing to _getTimeSinceLastServerResponse and we needed small adjustment of values as it may lead to no pings sent.
* feat: Make enableRemb signal client remb support.
* feat: Make enableTcc signal client tcc support.
* ref: Remove the enableOpusRed conference-wide option.
ref(JitsiConference): allow only 1 track per media type
Only one audio or video track is correctly supported by lib-jitsi-meet.
This is an attempt to mitigate an issue reported by the community
where the user's audio is played in the conference even though the UI
shows the user as muted.
fix(last-n): Do not let Jicofo initialize last-n for the whole conference.
The plan is to move the lastNLimits logic to bridge. The clients will be able to override(lower) the bridge limits through the bridge channel only. Also, this lets us configure last-n per receiver and not set the last-n value for the whole conference the way Jicofo sets it currently.
fix(TPC): Ensure encodings resolutions match configured values.
On every call to RTCRtpSender.setParameters(), ensure that the resolution configured for the encoding matches that of the value configured on the RTCRtpSender when the source was added to the peerconnection. This should prevent us from overriding the default values if the browser returns erroneous values when RTCRtpSender.getParameters is used for getting the encodings info. This fixes the issue on recent versions of Safari where the 'scaleResolutionDownBy' value comes back as 1 for all encodings even though the encoding resolution is different from the stream capture resolution.
In p2p mode, 'scaleResolutionDownBy' is used for downscaling a stream when needed, i.e. when the user receives a receive constraint of 360p because the other participant is in tile view. When desktop share is started, the encoding config has to be scaled back up so that the other participant starts receiving HD resolution for the share as desktop shares are autopinned. Therefore, encodings have to enabled/disabled for desktop shares as well. Earlier it was done only for camera tracks.
feat: Reduce pings and adds xmpp ping config (#1389)
* feat: Skips pinging when there was a recent server response.
* feat: Adds options to control xmpp ping settings.
* fix: Fixes wrong default value.
* squash: Received messages in ping interval sets failed ping to 0
fix: Add the x-google-conference flag on RD when screensharing.
Add the conference flag back since the bridge is able to handle the case where more than 1 temporal layers are received even when only 1 ssrc is signaled.
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.
dependabot[bot]
damencho
Jaya Allamsetty
Viktor Chernodub
bgrozev
Maxence Dalmais (maxired)
Pawel Domas
Saúl Ibarra Corretgé
Jorge Vallecillo
tmoldovan8x8
Philipp Hancke
Avram Tudor
Tudor-Ovidiu Avram
SaiKumar Immadi
Paul Tiedtke
Hristo Terezov