If the mobileCodecPreferenceOrder setting is missing, use the default order for mobile. Fixes an issue where mobile endpoints encodes using AV1 when mobile settings are missing.

It's not imported, so it wasn't being bundled.

The backend really sends upper case values:

3816e5a154/src/main/java/org/jitsi/xmpp/extensions/jitsimeet/TranscriptionStatusExtension.java (L82)

This was needed in older versions since the browser didn't apply maxBitrates from RTCRtpEncoderParameters on the encoder. In the newer versions this seems to be no longer the case. Also, when the codec selection API is used, we no longer renegotiate locally so if we switched codec from AV1->VP9-VP9, the AV1 bitrate setting in the SDP will still be effective resulting in a lower send resolution because of b/w limitation.

Leaves up to the backend to process or not process them.

Checking for send resolution vs expected resolution was unnecessarily limiting lastN and receive resolution when local camera has issues and stops sending video. Also, do not send redundant receiver constraints on the bridge channel

When using bosh and xmpp conference-request (no jiconop on server-side) we can drop av moderation and speaker-stats messages.

It will avoid having an extra "Canceling connection resume task" log
line every time we schedule a timer.

There is no hardm in calling it twice since we protect against it.

* Change jid to participantId

* Define participantId

When lastN is first set to some truty value and then 0, it wouldn't be
set because we relied on a "truthyness" check.

Check if the value is undefined so it can be set to 0.

When WebRTC ICE gathering policy is set to gather once instead of continually, the controlling agent goes to completed instead of connected (no more candidates to check). This doesn't happen in Chrome or other browsers, but is reproducible with node.js wrapper around WebRTC which runs with the default settings.

This is causing a bug where the initiator side of a P2P connection does not fully switch to P2P mode and keeps on sending data on both P2P and JVB connections.

It has been broken for over 3 years now, since ca325f5ef9 (diff-9e19da30f465ca5665ac3d7ca1aa03d0498aed1be0cb2d7eeb27684a2636da77)

Ever since that change, the "audioLevelReportHistory" property is not
populated, so it justs acts on nothing an generates bogus log lines such
as:

```
[modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant b5fb30bc, local audio levels: [null,null], remote audio levels: undefined
```

Since nobody seems to have noticed in 3 years it's safe to assume we
don't need this at all, so it gets the axe treatment.

* ref(QualityController) Add recovery mechanism and adjust the resolution check.
Impl a recovery mechanism for the lastN to be increased if the cpu limitation goes away and doesn't return after increasing lastN. Also, additionally improve the calculation of the expected resolution taking simulcast stream resolutions into account.

* squash: Address review comments and add more unit tests

* squash: Address review comments

* feat(quality) Add a QualityController class for runtime adjustments.
Make run time adjustments to the client when adaptive mode is enabled.

* feat: Update lastN and receive resolution to improve quality.

* squash: Address review comments

* squash: Add more logging and address review comments.

This prevents the browser from starting the camera at 60 fps wherever supported as this could drastically affect the cpu and result in poor experience.

* feat(silent): track if participant joined without audio

* Fix failing tests, use jitsi.org namespace

---------

Co-authored-by: Дамян Минков <damencho@jitsi.org>

We need the initial invite/answer to have the codecs in the correct order so codec selection API for selecting codecs is not useful in this case.

* feat(codec-selection): Use the new codec selection API
https://github.com/w3ctag/design-reviews/issues/836. This allows the client to seamlessly switch between the codecs without having to trigger a renegotiation.
This feature is behind the flag testing.enableCodecSelectionAPI in config.js

* fix(stats): Fix local resolution stats.
The video codec for the local video sources needs to identified differently now, from the codecs field in the RTCRtpSendParameters returned by the browser. We no longer munge the remote SDP to switch to a different codec.

* feat(stats): Feed encodeTime stats for all local SSRCs to the codec selection mechanism.

* fix(codec-selection) Continue to mumge SDP for selecting H.264.

* feat(codec-selection) Make screenshare codec configurable.
If no 'screenshareCodec' is set under videoQuality or p2p settings, AV1 will be selected as default.

* squash: Address review comments

* Update modules/RTC/CodecSelection.js

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

* fix(codec-selection) Add codec to existing stats

---------

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

Fixes poor low resolution video from Spot running older electron versions when the codec changes from VP9->VP8->VP9.

This helps us in identifying the video codec associated with a local video track for codec selection torture tests.

We are already handling Safari, which provides an empty constraints
object. Handle any type of broken constraints object which doesn't have
at least a `width` and `height` properties. This is the case of Firefox
when "fingerprint resistence" is enabled.

Fixes: https://github.com/jitsi/jitsi-meet/issues/14609

Claiming there is no support for it is misleading, the user might have
called the function before the channel was initialized.

It will now happen for both local and remote tracks.

Use an exponential backoff time for initiating ICE restart to prevent loading the prosody.

When a large number of endpoints loose connection to the signaling and media servers because of an ISP failure, these endpoints will try to reconnect at the same time causing a storm of source-remove/source-add events to the signaling servers that can lead to prosody going down otherwise.

The browser is downsampling the resolution since the current default bitrates for H.264 are very conservative.

It's very odd to start receiving events and logs about device changes
when lib-jitsi-meet has not been initialized yet.

Delay initialization until JitsiMeetJS.init has been called, which is
the very first thing users need to call anyway.

They have been deprecated and printing a warning for at least 7 years.

It's better handled by the application layer anyway.

In RN, an uncaught exception causes the app to crash in release builds.
We sidestep that on the native side, but RN SDK users usually don't, so
be gracefull.

Fixes: https://github.com/jitsi/jitsi-meet/issues/14728
Fixes: https://github.com/jitsi/jitsi-meet/issues/14399