This is the first step in adding support for multiple
streams per endpoint. Each source(stream?) needs to have
an identifier. For now always generate the 0 index name
until the machinery for sending more than 1 stream is put
in place.

* send only MSID attribute

* add feature flag for source name signaling

* log a msg if source name signaling is enabled

Maybe due to our DOM wrappers, the Symbol.iterator is not implemented, so
iterate over the IQ fields old-school style.

There was an error in the pattern match, everything was included in it. In
addition return a boolean in case we succeed in the UA pattern match, since it's
more correct than returning an array with the match.

If a second JitsiConference instance for the same room is created we were
throwing an error but some listeners were already attached. This commit
makes sure that we throw the error as soon as possible and no listeners
are added.

ChatRoom.setAudioMute and ChatRoom.setVideoMute are
not async, so no callbacks nor promises are necessary.

Instead of logging the full IQs for Jingle messages like session-initiate, source-add and source-remove which can be very long, log just the formatted source information.

It makes more sense to call it pcConfig since it is the RTCConfiguration object passed to the WebRTC peerconnection.

Log only the important events that we care about on the HTMLMediaElement that the remote tracks are attached to.

* feat(av-moderation) Remove from moderation whitelist functionality

* Fix comment

For some reason webpack seems to not be transpiling that properly.

Fixes: https://github.com/jitsi/lib-jitsi-meet/issues/1722

This fixes an issue where the bridge doesn't forward the HD stream from Firefox to other users in the call. The order of the ssrcs produced by the browser is from Highest resolution to lowest whereas the bridge assumes it to be from lowest to highest as is the case in Chrome and Safari.

If Jicofo doesn't offer VP9 but the client expresses a preference for VP9, VP9 bitrates were being imposed before.

Fixes issue with jibri that are served on different virtual host and jiconop2 does not work for them.

This is needed for screensharing to work as expected on chrome in unified plan.

... is stopped. If there's any sRD/sLD cycle happening
while the screen sharing stops, the local track
returns muted and it was injecting fake video SSRCs
which results in invalid SSRC description.

At the time when it happens there's error log in jicofo:
"Error adding SSRCs from X"
and the client will get bad-request error in response
to the source-add request.

We already log if a focus leaves, which the the important bit. This avoids a log
flood when leaving a large conference.

On mobile Safari, if a user joins audio and video muted, the browser doesn't decode the incoming audio. Workaround is to always add the audio track to pc and mute it if needed.

* feat: Support plain endpoint ID.

Support the ID of the owner of sources being encoded directly instead of
using the full JID.

* feat: Support JSON-encoded sources.

* feat: Advertise support for JSON-encoded sources.

* fix: Updates shard value in XmppConnection on new value from xmpp.

* squash: Start ws keep alive only after the successful connection.

An alternative to Insertable Streams, currently implemented in Safarii / WebKit.

https://w3c.github.io/webrtc-encoded-transform/

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

* fix: re-enable that ICE connection failures in Chrome are detected
* fixed linting errors

* enable config callstats configParams

* add comments

* wrap long comments

* fix format

* fix format

* fix format

* add jsDoc

Fixes Spot not being able to use the wireless screen sharing feature.

In unified plan we'll take the ssrcs off the first audio / video stream, but we
were assuming both would be present.

This commit fixes that, since the Spot wireless screen sharing feature uses a
dedicated TPC just with a video stream.

The prosody toJson returns for empty arrays {} which causes an error initially.

When the user first unmutes their video, the connection quality is shown as poor until the local stats are available.
Calculate the connection quality only after the stats are available, i.e., assume 100% until pcStatsInterval has elapsed.

This lets the bridge adjust the bitrate allocation for this source so that layers with higher fps are prioritized over layers with higher resolution.
As a result, endpoints with restricted downlink will receive a high fps low resolution share as opposed to a high resolution low fps screenshare.

Hurts mobile performance. They can still be enabled by setting the level at the
right value (debug / trace).

Hurts mobile performance. They can still be enabled by setting the level at the
right value (debug / trace).

remove legacy APIs which are not even supported anymore

Chrome doesn't create a decoder for ssrc in the remote description when there is no local source and the endpoint is offerer. Initiating a renegotiation with the endpoint as a responder fixes this issue. Add a workaround until Chrome fixes this bug.

* fix: Missed SSRCs in Unified Plan with several "ssrc-group:FID" groups.

`TpcUtils.ensureCorrectOrderOfSsrcs()` takes into account only the first `ssrs-group`, and it causes missed `ssrs` attributes. It results in an error during `peerconnection.setRemoteDescription()`.

For fixing `ensureCorrectOrderOfSsrcs()`, all `ssrs-group` are traversed and all distinct `ssrs` are preserved with keeping their order.

* test: Added extra tests for `TpcUtils.ensureCorrectOrderOfSsrcs()`

Munge 3 ssrcs in the SDP for chrome in unified plan always for the simulcast case.

Do not enable unified plan for p2p chrome by default until StartMutedTest is fixed.
Fix media direction for case when there are no local and remote sources, should be set to 'inactive' in that case.

Munge only the m-line that corresponds to the source that the browser will be sending.
Do not select VP9 on Firefox.
Detect support for RTCRtpTransceiver#setCodecPreferences correctly.

In unified plan impl, it is not possible to enable/disable simulcast during the call since the same sender is re-used for all local video tracks. Therefore, disable the low resolution simulcast streams for low fps screensharing so that the bridge forwards only the highest resolution stream which is important for low fps screensharing.