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

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.

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.

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

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.

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.

remove legacy APIs which are not even supported anymore

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

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.

Provide a method for changing the capture fps for desktop tracks during the call. These changes to the lib are needed for making it configurable from the UI.

When the resolution option was being used, all the other constraints like frameRate and facing mode were being overwritten.

Set the initial video type state to NONE to cover cases when the endpoint joins video muted.

Use 'msid' for plan-b clients and 'cname' for unified-plan clients.

Browsers do not generate a 'msid' attribute for ssrcs in unified plan mode, use mediaType as a key for the TrackSSRCInfo map.

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.

Call RTCRtpTransceiver#setCodecPreferences with the preferrred codec order before every createOffer/createAnswer. This ensures that the codec preference is enforced even when there is no local description available yet while the preferred codec is being set immediately after media session creation.

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

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

Avoid configuring the encodings on Chromium/Safari until simulcast is configured for the newly added track using SDP munging which happens during the renegotiation.

Avoid configuring the encodings on chromium immediately after replace track since the encoding params are read-only until the renegotation is done.

This fixes the issue where TRACK_REMOVED event is not fired when a remote track is removed from the peerconnection.
Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1612 and https://github.com/jitsi/jitsi-meet/issues/8482.

Get the correct media type when generating the source identifier.

When a msid attribute is missing in the 'a=ssrc' line, use the local endpoint id as an indentifier. Move this generation logic to LocalSdpMunger. Also suppress notifying Jicfo of a ssrc change on Firefox when the change is a result of the media being suspended on the jvb connection.

Get rid of noisy logs related to SDP transformations which are redundant. Fix formatting and add missing information.

Do not send old format constraints if no constraints are set before the channel is initialized.

Do not try to configure encodings on the sender until they are available. This fixes an issue on Chrome (running in unified-plan mode) where unmuting the local source throws a 'Read-only field modified in setParameters()' error.

SDP utility classes are spread across RTC and XMPP directories now, moving these class files to a 'sdp' directory.

Switch to returning a Promise for getStats. Reset frame rate stat to 0 when video is suspended as a result of endpoint falling out of last-n.

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

Disable simulcast for low fps screenshare and enable it for high fps screenshare. testing.capScreenshareBitrate config.js setting has now been deprecated.

* fix: high CPU on Chrome with low fps screen sharing

It turns out that if 5 fps is set on the track constraints,
Chrome will capture the original video in 30 fps and only
further down the pipeline will downsample it to 5 fps.
This results in very high CPU usage. Specify max FPS in
getDisplayMedia to fix the problem.

Getting rid of track.applyConstraints should also fix another
issue on Firefox where it reports 0x0 screen size after this call.

* ref(RTCUtils): remove trackOptions

* remove extra &&

Get rid of the browser specific keys and use the standard spec-compliant fields for stats.
Get the resolution/fps for remote streams from 'inbound-rtp' stats. Use the 'track' stats for the local resolution/fps since these take the active simulcast streams into account.