The XmppConnection will try to resume the connection
only when the internet is online. This speeds up the process
by avoiding unnecessary connect attempts while offline as each
failed attempt increases the backoff delay.
ref(video-quality): Resolve sender operations when RTCRtpSender/RTCRtpSendParameters are not found.
The constraints are applied again after renegotiation is done. This should mitigate a fail case on Safari when the RTCRtpSendParameters are not available until the simulcast streams are added via SDP munging before sLD is called.
There's a plan for using ping to detect XMPP WebSocket
disconnected instead of waiting for timeouts on the network layer.
This also simplifies ICE failed handling logic.
...in setMediaTransferActive. The sender video constraints
are controlling the 'encoding.active' flag and this code
would interfere. It's right now not used anyway as P2P is
disabled in the unified mode. If this modification is
necessary we'll add it back when working on unified P2P
in such a way that will play nicely with the sender constraints code.
...when starting without video.
The app would crash in setSenderVideoConstraint,
because the RTP encoding are not available on Safari
until sLD/sRD cycle is performed.
ref: Moves xmpp logs to be accessed from connection. (#1284)
* ref: Moves xmpp logs to be accessed from connection.
In cases where there is no room like pre-join and lobby screen we still want to be able to debug xmpp messages.
* squash: Remove getLogs from Conference.
* squash: Fix catch.
* squash: Print the error.
fix(video-quality): Get downsampled video for p2p case
When the video sender constraint changes in the p2p case when the remote user switches between stage/tile view,
get a downsampled video of the original 720p stream instead of requesting the camera for a new stream with the lower resolution.
Fixes https://github.com/jitsi/jitsi-meet/issues/7267
* feat: Apply max bitrates on video sender
Add the ability to control the max bitrates on the video sender through a config.js videoQuality setting.
* ref: Use '_' prefix only for internal methods
Add a performance stat around long tasks. Chrome supports PerformanceObserver API that lets us
register for long tasks event. Any task that takes longer than 50ms is considered a long task.
fix: Scale remote audio levels reported on receiver to getStats levels
The audio levels reported on the audio receivers are lower when compared to the value reported by getStats.
Values reported by getStats on chrome do not follow the the spec and since we have combination of clients using both getStats and getSynchronizationSources,
lets stick to one scale to make them look uniform.
Also, the receivers seem to be reporting audio level for a little bit after the remote user has muted. Make sure the track is unmuted
before setting the audio level on the track.
fix(StropheLastSuccess): refresh the timestamp in connected
An 'item-not-found' or other error on Websocket reconnect will refresh
the timestamp which will give misleading information about when
the last stanza was received.