Instead of Jicofo signaling all the remote sources available in the call, the bridge now signals only a limited set of SSRCs and then rewrites the SSRC on the outgoing media streams. The SSRC mapping is done based on the sources requested by the clients through the receiver constraints. This limits the number of m-lines in the remote/local SDPs on the client and therefore results in better performance in large calls.

* Handle source remapping messages from bridge
* Added track_owner_changed events
* don't process an invalid rtx ssrc.
* keep track of remote ssrcs, only renegotiate on new ones.
* Change source name on remote track on ssrc remapping.
* Don't remove tracks on member leave.
* Remove (orphaned) tracks on session terminated.
* Use serial number (per media type) to create msid attribute.
* Update videoType on remapping.

Co-authored-by: James A <jqdrqgnq@users.noreply.github.com>

* fix(codec-selection) Munge all related m-lines for multi-stream.
Munge all the video m-lines to apply the preferred codec settings in multi-stream mode.

* fix(TPC) Cache transceiver mids for all local video tracks.
There will be multiple video tracks in multi-stream, we need to cache the mids for all the the associated transceivers.

* fix(sender-constraints) Do not apply sender constraints if value hasn't changed for a given source.

* fix(TPC) Configure the direction correctly for all m-lines.
Ignore negotiationneeded events for p2p to avoid going into a renegotiation loop.

* squash: Address review comments.

Fixes cases where SS fails in multi-stream mode with p2p->jvb->p2p switching.

Avoid needing an external dependency.

Fixes cases where SS stream is not being sent when p2p->jvb switch happens.

Allows a moderator to end the conference for everyone.

Co-authored-by: Werner Fleischer <70745309+wernf@users.noreply.github.com>

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

When an answer is received from the p2p peer, only set remote description instead of calling the full renegotiation cycle. Also, always initiate a sRD->cA->sLD cycle when adding remote sources irrespective of whether the local endpoint is an initiator or responder for the p2p connection. This lets us remove the hacks added for Chromium (unified-plan) bugs related to video not rendering in p2p cases.

fix up test failure by including extends Listenable

Since Track effects and mute/unmute operations use the same flow, i.e., removing/adding the track from the RTCPeerConnection but not from TPC, make the names of the methods involved more generic.

They are always required and the signaled features are ignored.

* Add a receiveMultipleVideoStreams flag.

* fix(SignalingLayer): Skip checking for last presence if the client doesn't join muc.
This fixes the broken wireless screensharing issue on spot clients.

* squash: change log message to a warning.

* fix(deployment-info) Prevent error when setting shard and region

* fix

Adds it to deploymentInfo.

With just source-name enabled, set the source name of the replaced track before configuring the encodings, this fixes an issues where the sender constraints are not applied on the p2p connection because the source name is undefined.

* Revert "fix: Cleans up rooms after failure to join."

This reverts commit f23372dd88.

* fix: Cleanups JitsiConference on reservation and max user failures.

* fix(video-quality) Update frame heights in content-modify for p2p.
When the user changes the preferred video quality settings from the UI, update the frame height values in content-modify for p2p connection when source-name signaling is enabled.

* fix(multi-stream) Send presence for desktop track before signaling when it is the first track to be added to the conference.
Also do not suppress renegotiation for desktop track on p2p since the browser doesn't fire negotiation needed event.

* squash: fix build

* squash: fix linter issues

* squash: add comment.

When source-name signaling is enabled, get correct peermedia info when the peer sends presence in the legacy format. This fixes an issue where Jigasi users cannot be heard by endpoints that have source-name signaling enabled.

* fix(multi-stream) add new m-line when remote adds a second video source in p2p.
A new m-line needs to be added in the remote description when a new secondary video source is signaled by the peer.

* fix(TPC) Suppress lower layers only for screenshare tracks.
With multi-stream support enabled, an extra check for videoType for local track is needed to dtermine if the lower layers need to be suppressed.

* fix(TPC) Mark the direction inactive on inactive media connection.
If a new secondary video source is added on the jvb connection while p2p is active, make sure the direction is set to inactive on the jvb connection, so that no media is being sent out on the jvb connection.

* squash: Address review comments.

* fix: Set affiliation.

XEP-0045:
Affiliations are granted, revoked, and maintained based on the user’s bare JID, not the nick as with roles.

* squash: Fixes own revokeOwner.

Handle presence updates for multiple sources per remote endpoint.

Also switch to using signalingLayer.getPeerSourceInfo during remote track creation when source-name signaling is used.

We do not want the client to re-use the inactive transceivers that are associated with m-lines for removed remote tracks. Rejecting a m-line on source-remove clears it from the list of available transceivers.

If there are more than one video track at pc creation time, add them sequencially to avoid renegotiation loop.

* fix(multi-stream-support) Support muting of desktop track.

* fix(multi-stream) Always initiate responder renegotiation even for p2p.
This is needed since the new m-line is always added to the remote description.

* fix(multi-stream) Support multi-stream only on Unfied plan endpoints.

* fix(multi-stream) Advertise source-name signaling to Jicofo when supported.

* fix(JitsiLocalTrack): Remove unnecessary reject.

* fix: add the correct source name attribute for the second video track.

* squash: Address review comments.

In P2P and unified mode, Chrome does not render the media if an SSRC is removed and the same one is added back (happens when the sender is camera muted->starts SS->stops SS->turns camera on). That is why SSRC was not being removed. However, mobile endpoints that are running in plan-b generate a new SSRC when the client switches between camera and screenshare. This will cause issues on a p2p receiver that is running in unified mode. Fixes https://github.com/jitsi/jitsi-meet/issues/11010.

Recycling the m-line by rejecting it and then re-using is causing issues where sometimes the track addition fails. When a new ssrc is added to an m-line that was rejected and port is changed back to the default port, sometimes the remote sdp returned by browser wouldn't contain the newly added ssrcs and the track addition fails as a result.
Error: No SSRC lines found in remote SDP for remote stream[msid=854882f8-audio-1,type=audio]
    at Ca._remoteTrackAdded (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:439103)
    at Ca._usesUnifiedPlan.onTrack (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:432207)
    at RTCPeerConnection.r (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:680736)
.

It's possible we get sender constraint messages while operations to
change the direction in the JVB session are in progress so we currently
have no predictable way to properly suspend video without races.

Since this will be solved when we move to transceivers, this is a
compromise we are making.

Fix having duplicated audio due to the JVB connection being re-activated
once the sender constraints change.