All the send video constraints for the client, i.e., what simulcast streams will be enabled based on constraints received on the bridge channel, will be handled by the SendVideoController class.
The receive video constraints like lastN, selectEndpoints and receive video resolution will be handled by the ReceiveVideoController class.

Force the client to reload when the bridge that is handling the media goes down.
This mitigates issues seen on the bridge because of a client re-joining the call with the same endpointId, BWE issues, etc.
This behavior is configurable through 'enableForcedReload' setting in config.js.

RN doesn't support RTCRtpSender yet. Therefore, media is suspended on RN by changing the media direction in the SDP whenever the client receives an ideal height of 0 for sender constraints on the bridge channel.

After ICE failure and subsequent recovery of the media connection to the bridge using session-terminate, the local connection status needs to updated when ICE connection is established on the new peerconnection. The local connectivity status will be shown as Lost otherwise.

Determine the preferred codec for a given endpoint based on the config.js settings and the codecs supported by the endpoint.
The preferred codec is published in presence and then used by the other endpoints in the call during join/leave to determine
if the codec needs to be changed on the fly. Different codecs can be configuered for p2p/jvb connections.
The preferredCodec/disabledCodec settings under videoQuality will have precedence over the older settins like preferH264/disableH264.

Configure the encodings on FF after the track is added.

Calculate the bitrate based on the sender video constraint applied on the track and the bitrates specified for different resolutions.

Use 'preferredCodec' and 'disabledCodec' under videoQuality config.js settings for setting codec preferences.
Do not prefer VP9 on Firefox because of https://bugzilla.mozilla.org/show_bug.cgi?id=1633876.

Make sdp munging logic for changing codec preferences more generic
Do not negotiate High profile H264 codecs on when RN clients are in the call

Handle the promise returned by RTCRtpSender.setParameters.

* feat: Apply max bitrates on video sender
Add the ability to control the max bitrates on the video sender through a config.js videoQuality setting.

* ref: Use '_' prefix only for internal methods

Delays e2e encryption initialization until any encryption key is set.
Recreates peerconnections in order to enable insertable streams
only if the e2ee is used. This is to avoid bug around insertable streams
which may cause audio issue when the main JavaScript thread is loaded:

https://bugs.chromium.org/p/chromium/issues/detail?id=1103280

* feat: Set degradation preference on video senders
Use 'maintain-framerate' for camera tracks and 'maintain-resolution' for desktop tracks

* ref: apply cached video contraints and degradation preference on unmute
Since the sender encodings are available only after the renegotiation is complete (on chrome/safari), constraints/preferences have to be applied after renegotiation is complete.

Refactors the way send/receive video constraints are managed and puts the high level
logic in a separate module. See QualityController.js for high level overview on how
the constraints are managed now.

Adds events to JitsiConference fired whenever it starts new jvb/p2p session.

Adds event to JingleSessionPC.js when remote party signals receive max frame height.
Also adds signaling of the local recv preference for the p2p mode(only existed for JVB).

Switches from using JitsiConference.isJvbConnectionInterrupted
flag to peerconnection's ICE state. The interrupted
flag is not set if the connection fails initially.

Audio fails on Safari when we try to re-use audio m-lines whose direction has been set to 'inactive'
when the remote source left the conference.
Disable noisy mic detection on Safari as this causes audio input to fail on Safari on iPadOS

A new method which not only has Promise interface,
but also allows to queue IQs regardless of the current
connection's status.

Ping and send ICE failed notification requests are changed
to use this method which makes it more reliable on XMPP
Websocket connections on mobile(which in contrary to BOSH
dies much faster there).

* feat(video-quality): control the sender resolution based on video quality settings

* fix(video-quality): Apply the settings on newly created p2p/jvb jingle sessions
If a p2p/jvb session is not present when setSenderVideoConstraint is called,
make sure the settings are applied when they are created

Get rid of the experimental flag for simulcast support, update js-utils for detecting Edge on Android

Trigger renegotiation only for plan-b when tracks are muted or unmuted

Switch to using ontrack for remote tracks, re-use mids/transceivers when remote sources are removed and added.

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

Trigger renegotation only when negotiationneeded event is fired on the browser.
Do not disable simulcast for screensharing in unified plan.
Fix the order of the simulcast streams for Firefox

Given that the XMPP connection is able to reconnect after a drop, now
the jingle session needs to hold off any updates that have to be sent
while the signalling is down. Send the update upon reconnect to sync
Jicofo and JVB with the client's source description.

All calls to connection.send should go through the wrapper in order to
prevent breaking the connection by calling it in the not connected
state.

We add the capScreenshareBitrate value to the permanent properties so
that it's included with every event that we send to the analytics
backend.

Enable/disable this feature using 'capScreenshareBitrate' testing flag in config.js and send analytics
events to Amplitude to indicate which type of screensharing is enabled.

The client will reject P2P session-initiate if the conditions which
allow for P2P session to start are not met(there more or less than 2
human participants in the call).

If DTLS fingerprint remains unchanged after ice-restart there will be no
media flow even thought the ICE connection will be re-established.
That's because JVB has all layers re-initialized from scratch, but
the WebRTC stack will keep the current state of the DTLS layer.

Reset the DTLS layer by setting an all zeros fingerprint on the hacky
offer/answer cycle which is currently done in order to reset the data
channels and the sequence number counters on the RTP receivers.

Also do not execute any peerconnection callbacks like
'oniceconnectionstatechange', 'onicecandidate' etc. after close.

Make the client send ICE failed notification to let Jicofo know
that the ICE connection with the bridge has failed. It can then
re-create the channels and send new transport in the
'transport-replace' message to give it another try.

Also adds a bridge session ID so that Jicofo can discard outdated
requests. When a bridge dies multiple clients may send ICE failed
notifications at the same time. Jicofo will detect bridge failure
when processing the first one and it must not act on the following
requests for the broken bridge session which is no longer current.

A bridge session ID will be sent in new 'bridge-session' XML element
which is part of either 'session-initiate' or 'transport-replace'
message. The server's region is moved to this element as well as
it's part of a bridge session.

Reset the state of remote MediaStreams in order to fix sequence number
synchronization problem. When a conference is moved to another bridge or
if channels are re-allocated the bridge looses the most recent sequence
number seen by the client which makes Chrome drop all video packets
until the JVB catches up with the sequence numbers (if at all).

Changes the behavior to actively open new WebRTC Data Channel instead
of waiting for the JVB to do it.

Adds ICE_RESTART_SUCCESS event used to re-initialize the data channel in
case of ICE restart where the conference could have been moved to
another bridge.

Keeps it consistent with the previous implementation.

It's 2018 after all...