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.

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.

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.

* 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.

* 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.

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.

The encodings for local video tracks are confiugured based on the SenderVideoConstraintsV2 constraints received from the bridge. The constraints are sourceName based. Also ignore enableLayerSuspension flag since it has been deprecated and layer suspension has been enabled by default. Also having it off makes screensharing on Chrome in unified plan not work as expected.

* feat(multi-stream-support) Add the support for multiple local video streams.
This feature is behind 'sendMultipleVideoStreams' config.js flag and is currently supported only on clients running in Unified plan mode.

* squash: Use the track index from source name to find the matching transceiver on unmute.

When a user leaves, the ssrcs associated with the ep are removed from the remote description and a renegotiation is forced. The browser then fires 'removetrack' event on the associated MediaStream when sRD is called with ssrcs removed. The remote track is then disposed of in the event handler. Therefore, there is no need to delete the tracks at the TPC level before renegotiation. This also prevents the 'Removed track not found for stream' events from showing up in the browser console log.

* ref(JingleSession) Recycle m-lines by rejecting them on source removal.
By rejecting the m-lines on source removal (setting the port to 0 on the associated m-line), m-lines can be recycled for new sources instead of appending new ones.

* chore(deps) update sdp-interop@latest.

* fix(RTC): fixed typo in function name

* fix(xmpp): codec renegotiation task needs to be queued

* fixed typos

* feat: Adds events for session-add, session-remove and session-accept.

* feat: Refactor updating presence for audio/video mute and video type.

This brings few changes and fixes. Thew initial presence will always miss audioMuted and videoMuted value, those will be added on session accept. All updates to presence are done on sessionAccept, on source-add or on source-remove and the only one not signalled when camera track is replaced by video track and vice versa.
This change brings more presence updates when number of participants are below startAudioMuted/startVideoMuted, but when participants are above those numbers we get less presence update. This is important for big meetings.
Fixes wrong videoMuted state, as replace track and mute are both executed in promise, sometimes the replace-track one finishes first and when the mute one is resolved there is no conference object in the track to be able to update the presence (hitting this when we pass the startAudioMuted threshold).

* squash: Put back the tracks for _setTrackMuteStatus and _setNewVideoType.

* squash: Fix line length.

* squash: Fix skip sending presence twice.

* squash: Adds the error to the error callback.

* squash: Fix newJingleErrorHandler.

* Save track source name to JitsiRemoteTrack

* add feature flag checks. code review adjustments.

* eslint cleanup1

* eslint cleanup2

* fix: move sourceName declaration outside of if block.

Co-authored-by: Dennis Dowhy <ddowhy@gmail.com>
Co-authored-by: William Liang <wliang67@bloomberg.net>

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

We do not have to wait for the removal of the ssrcs from the remote description for removing the remote tracks associated with a participant that left the call. This speeds up removal of the participant from call even if the JingleSession modification queue is backed up.

This fixes https://github.com/jitsi/lib-jitsi-meet/issues/1759.

Instead rely on the 'negotiationneeded' event fired by the browser for JVB connection. This makes local source changes faster even if the modification queue is backed up.

* ref(TPC) Configure encodings in one go.
Configure the active state, maxBitrate and degradation preference in one go instead of configuring them separately.

* squash: Address review comments.

* squash: fix a comment.

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

* 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: re-enable that ICE connection failures in Chrome are detected
* fixed linting errors

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).

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.

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.

In unified plan, re-use of m-line (i.e., adding an SSRC, removing it and then adding it back) causes the browser to not render the media on Chrome and Safari. The WebRTC spec is not clear as to how browsers have to behave, this doesn't cause any issues on Firefox. As a workaround, only change the media direction and leave the ssrc in the remote desc. This automatically triggers a 'removetrack' event on the associated MediaStream and the track can be removed from the UI.

For p2p connections, the media direction needs to be adjusted after every source-add/source-remove is processed based on the availability of local sources.

Disable cross browser p2p using unified plan until all the issues are fixed.

The 'signalingstatechange' event for 'stable' is fired after the 'iceconnectionstatechange' event for 'completed' is fired on chrome in Unified plan. This prevents the client from switching the media connection to the p2p connection once the ice connection for p2p gets established.

Add a preifx to logs for idenitifying the type of TPC/jingleSessionPC.

This can be controlled through the config.js  option 'enableUnifiedOnChrome'.