Calls to insertDTMF will stop any tone
playing in progress. Prevent such by
checking the tonebuffer for any tones
in play and queue tone playing if
any tones are in play.

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.

Moves sendTones implementation to TraceablePeerConnection. It will be
responsible for creating/storing a DTMFSender. JitsiConference will
use the currently active TraceablePeerConnection to send the tones.

This fixes a bug where DTMF tones can not be sent after
JingleSessionPC/TraceablePeerConnection instance changes.
The JitsiDTMFManager instance was referencing invalid PeerConnection.

In TraceablePeerConnection: we're no longer injecting a recvonly SSRC
when the local video track is muted, so it's normal that there is no
SSRC found in the local SDP when it's muted.

About RTPStatsCollector: at the time of adding this log statement a case
was missed when local audio track could be replaced in the P2P
connection when a new audio device is selected.

Starting in Chrome 71, tracks without a stream are
given the msid "-", which in plan b incorrectly
triggers an onaddstream even with a default local
stream.

Until M69 Chrome used to consistently emit "onstreamadded" when
audio/video stream is added for the first time and then emit track
events only if the stream is modified afterwards (video track replaced).

However it looks like now it can first emit "onstreamadded" and then
additional "ontrackadded" for the MediaStreamTrack that was already
included in the MediaStream signalled by the "onstremadded" event. I
have not managed to figure out what is causing this and the only
difference in the SDP is the fact that the remote peer (JVB) includes
IPv6 candidates. Anyway it doesn't hurt to have such a safeguard.

Just skip it in such environments, such as React Native.

This function helps simplify the code when handling browsers that are pretty
much Chrome in disguise.

Keeps it consistent with the previous implementation.

It's 2018 after all...

* Change layer suspension to use parameters in RTPSender

We no longer suspend unused simulcast layers via a bandwidth cap in the
SDP, instead we'll use the new parameters in RTPSender to enable and
disable streams explicitly.  The main advantage here is the RTPSender
method ramps up immediately when we re-enable the layers (as opposed to
the SDP bandwidth cap which took 30+ seconds).

* Fix linter issues

* Support layer suspension

Add support for a message which notifies the endpoint whether or not it
is selected (meaning its HD stream is in use).  If it is not
selected and enableLayerSuspension is set to true then it will impose a
bandwidth limit in the SDP to suspend sending the higher layers.

* only add the IS_SELECTED_CHANGED listener in JingleSessionPC if layer
suspension is enabled

this prevents doing a local o/a when we don't need it

Adds stats and audio levels for Safari. Enables the new getStats API for Firefox, that will get rid of the following warning:
'non-maplike pc.getStats access is deprecated, and will be removed in the near future! See http://w3c.github.io/webrtc-pc/#getstats-example for usage.'

This PR exposes the functionality that's already built-in the
TraceablePeerConnection that has it gather stats from the wrapped
PeerConnection.

This commit will append "-" + tpc.id to every local 'MSID', 'cname',
'label' and 'mslabel', before feeding the local SDP to the Jingle layer.
It will make stream IDs unique across TraceablePeerConnection instances
and prevent from conflicts in some corner cases.

For example this will fix a problem where if the client drops
the conference without leaving the XMPP MUC gracefully and will join
the conference again without recreating the local tracks it would lead
to the MSID conflict, because the stream is still advertised by
"the ghost" participant.

In order to include browser capabilities in RTCBrowserType I needed to
refactor RTCBrowserType.

In Rect Native it will stall the app as it's huge.

jitsi-meet has been changed to have tpc.js on info by default, so these
logs still won't show by default.

Calling JSON.stringify on a temasys object causes a stack overflow.
The result is that the JingleSessionPC's work queue never gets
cleared so future work, like video muting, will not get called.
Instead of passing in the candidate directly, manually do
what chrome's implementation of candidate.toJSON does.

Adds rtc.LOCAL_TRACK_SSRC_UPDATED event to be emitted when ssrc is updated for a local track.
Fixes adding rtc listeners for CREATE_ANSWER_FAILED, CREATE_OFFER_FAILED, SET_LOCAL_DESCRIPTION_FAILED, SET_REMOTE_DESCRIPTION_FAILED.

Error handling was added to ensure some munging helpers
were receiving RTCSessionDescriptions. Temasys is doing
something else and is passing its own object into
the mungers. So, let temasys do that.

IE11 errors when adding a temasys media stream object to
a Set. So instead use an Array.

Safari will fail to set its remote description if no
supported video codecs are found. This can happen with
config.p2p.disableH264 set to true, as browsers will strip
H264 from their offers. To get around this problem in a way
that can be removed once this is fixed on Safari's side,
add a function to inject H265 before setting the remote
description.

* ref(sdp): lower logs about missing local video to warning

* ref(sdp): earlier error handling for missing description and mlines

* ref(sdp): rename maybeMungeLocalSdp to be more specific

Firefox has deprecated modifying a description's sdp through
re-assignment. Safari (without temasys) does not allow it.
As such, wherever the sdp has to be modified instead create
a new description with the modified sdp.

- Add a new browser check so adapter shim usage can be gated.
- Get track resolution for stats from the track itself to account
  for browser resolution fallback logic. Do this only if
  we can be sure adapter has shimmed it in.
- Create a new getUserMediaFlow, with RTC being the orchestration
  for various RTCUtils calls.
- Remove connection quality stat "resolution" which was being
  emitted but not used but listeners.

This is performed by stripping all traces of H.264 from the local SDP before
passing it to `setLocalDescription`.

ESLint 4.8.0 discovers a lot of error related to formatting. While I
tried to fix as many of them as possible, a portion of them actually go
against our coding style. In such a case, I've disabled the indent rule
which effectively leaves it as it was before ESLint 4.8.0.

For p2p, we have to take preferh264 into account when setting the local description, since
that prefer is what will be received by the far side.  if we only do it on the remote description,
like before this change, we'll never actually end up preferring h264.

The 'setMutedInProgress' flag is unreliable and it can lead to weird
situations when mute operation is in progress, but the removal from
JingleSessionPC is waiting on the queue. In such case LocalSdpMunger
will fake SDP even if the track is in the PeerConnection which may
confuse some parts of the SDP transformation chain.

For example RtxModifier will not attempt to inject Rtx group description
if it sees that the SSRC are already there. But it can happen that even
though the SSRCs are there they do not contain valid track ID, because
the track has changed.

The LocalSdpMunger is supposed to fake the SDP only when the video
MediaStream is not in the PeerConnection. So this commit implements just
that: a way to tell if JitsiLocalTrack's stream is currently in
the PeerConnection (added through TraceablePeerConnection).

* add support for signaling simulcast for unified plan

1) munge the incoming offer to advertise support for receiving simulcast in unified plan
2) add 3 simulcast encodings via rtp sender
3) inject an ssrc-group line, even when using rids for simulcast (jicofo will rely on this)

* add rid information to the session-accept jingle

* address lenny's feedback

* make firefox simulcast configurable

* fix missing comma

* ref(JSPC): simplify SSRC owner in P2P

There's no need for any extra extensions for SSRCs owner signalling in
P2P, because it's always the remote peer who owns them.

This also fixes a problem where no SSRC owner was added for 'source-add'
in P2P (for JVB conference Jicofo adds that).

* fix(TPC): always advertise 'sendrecv'

Our media direction is only ever updated on the remote side with
the initial offer (or answer). Because of that we want to advertise
'sendrecv' even if we start with no video (or audio) track.

It is OK to adjust this direction in the localDescription getter,
because it's adjusted again in the setter to the correct value based on
local tracks, so the SDP transformation chain still works fine.

When the lastN is set to 0 the P2P session will notify the remote peer
to stop sending video.