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

In case there was a status message and later that message is removed from the presence, fire an event so the UI can also clear it.

via JSON messages received via the Chatroom

Moves the call to 'setLocalDescription' from 'sendSessionInitiate' to
'invite' as it was easy to overlook.

In case when the answer is being set for the first time, full sRD/sLD
cycle is required to have the local description updated and SSRCs
synchronized correctly. Otherwise SSRCs for streams added after invite,
but before the answer was accepted will not be detected. The reason for
that is that renegotiate can not be called when adding tracks and they
will not be reflected in the local SDP.

The 'ondatachannel' even listener must be set as soon as
the TraceablePeerConnection is created and before the offer is accepted.
We've observed situations where the ondatachannel event was missed,
because the listener is bound too late from the JingleSessionPC
'acceptOffer' success callback.

If we detect a custom <ignore tag in presence unavailable we ignore those presences and do not process them.

* 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

Due to it being ran asyncronously, it's possible a replaceTrack operation is
scheduled while there is a valid PC, but by the time it runs was closed.

Accommodate to this situation by pretending everything is just peachy.

Old config.js versions don't have the p2p property.

* ref: Moves the deployment info variables to config.js

instead of using globals.

* feat: If configured, adds the user's region to presence.

* fix: Guards against accessing undefined properties,

and uses the crossRegion variable from the config.

* style: Fixes formatting.

Until we have a default config template, make sure we default to having P2P
enabled.

Also add a preferH264 option for P2P.

Some browsers may not support data channels (hi there, Edge!) and sometimes it
may not be desirable for other reasons.

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

Will crash the code early in case one of the value is undefined (it will
crash later anyway, but makes it harder to guess).

This code would crash on react-native if 'sdpMid' is not defined at all.
Still works as expected with an empty string though.

Adds session converted to string to the error object.

Do not log errors for 'item-not-found', after jingle session was
terminated.

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

Creating SDP instance was unnecessary.

Will actively terminate P2P session by the responder (not moderator) in
order to shutdown P2P in case of eventual initiator's crash. Otherwise
the responder will stay in P2P for too long (until P2P ICE fails).

Prevents from printing Jingle 'session-terminate' error response in case
both responder and initiator terminates their sessions simultaneously
(gracefully). In that case 'item-not-found' error is returned by each
party, because the session is removed immediately from the memory on
termination (see strophe.jingle.js).

Each JingleSessionPC must be marked as ENDED from "onTerminated" or
the underlying TPC instance may not be closed and remote tracks could
leak.

If for any reason invite for the JVB JingleSession is delayed and
arrives after the P2P connection has been established then
the media transfer needs to be disabled after the offer is accepted.

Invite must be executed on the queue to avoid strange things happening
on the beginning of the call. For example when the local tracks are
added just after the invite was called.

Move the JingleSessionPC to ACTIVE state, as soon as the first
_renegotiate is executed in PENDING state.

* feat(JSPC): ICE establishment time

Will report total ICE establishment time under
'ice.initiator.establishmentDuration' and
'ice.responder.establishmentDuration' ('p2p.' prefix added for P2P).
It's the amount of time between the time when either checking or
gathering started (whichever starts first) and when ICE entered
'connected' for the first time.

* fix(JSPC): simplify and rename event

* ref: store SSRCs as a number

Converts all the places where SSRCs where stored as string to use
numbers.

* doc(RTPStatsCollector): getNonNegativeStat

Fixes invalid description about returning NaN.

* ref(JitsiConf...EventManager): simplify for..of

* ref(JitsiRemoteTrack): throw TypeError

Will throw a TypeError when 'ssrc' is not a number.

* fix(RTPStatsCollector): invalid reference

* doc(RTPStatsCollector): getNonNegativeStat private

* ref(RTPStatsCollector): simplify for..of

* fix(SSRCs): check for negative value

Will not accept negative SSRCs, since those are supposed to be unsigned.

Token is passed as parameter when creating JitsiConnection and we no longer use it from the options passed to the connection.

Will emit analytics events for ICE gathering and ICE checks duration,
separately for initiator/responder and p2p/jvb connections. Initiator
and responder have to be separated, because the flow and the values have
significant differences.

XMPPEvents.CONNECTION_ESTABLISHED is emitted outside of 'is stable'
condition, because for the JVB connection the signalling state is often
not in 'stable' ('have-remote-offer') state when ICE goes to
'connected'.

Webpack 2 defines module.exports as a read-only property in ES6 modules.

Currently, when a participant joins hidden/video muted, we add a
recvonly SSRC so that the client sends RTCP reports with that SSRC. This
SSRC doesn't have neither simulcast nor RTX enabled. When the user
decides to enable his video camera, we "enhance" this SSRC with params
for RTX and simulcast. However, Chrome does not take into account these
new params because of
https://bugs.chromium.org/p/webrtc/issues/detail?id=7555. By not adding
a recvonly SSRC, we activate the default behavior in Chrome which is to
send RTCP reports with SSRC 1. So, when the user decides to enable his
video camera, instead of updating/enhancing the existing SSRC, we
initalize the primary SSRC with the correct params.

Sending the bare jid, speeds call setup as otherwise jigasi needs to do a feature discovery finding the conference component address and use it to construct the room address to join.

Webpack 2 defines module.exports as a read-only property in ES6 modules.

* fix(JingleSessionPC): do not log whole object
* fix(JitsiConference): fix a crash

The code will crash if there's neither P2P nor JVB session yet.

ICE connection state analytics for the JVB connection should not be
mixed up with the ones for the P2P connection.

* ref(JSPC): rollback doRenegotiate

Modify the code to the old strategy without shared 'doRenegotiate'
method.

* ref(JSPC): add/remove duplication

Removes duplication between add and remove remote stream methods.

* fix(JSPC): remove Timeout

Removes wait timeout for remote stream added/removed. It should not be
necessary given that the task executes on the modification queue and
the initial offer/answer should execute before
'source-add'/'source-remove'. Jingle 'session-invite'/'session-accept'
is sent, before any other notifications.

* feat(JSPC): verify SSRC changes

Will print an error if there was change to local SSRCs where it should
not happen (video mute on browsers where video stream is disposed on
mute).

* fix(JSPC): not always renegotiate

When adding/removing tracks as mute/unmute it only makes sense to
renegotiate if the initial offer/answer cycle has already been executed.

* ref(JSPC): remove duplication

Removes duplication around add/remove as unmute/mute.

* ref(JingleSessionPC): add local tracks with offer/answer

Refactor the current code to add local tracks together with initial
offer/answer to make this atomic/single operation on
the modificationQueue.

This is required to be able to get rid of 'delayedIceCandidates' list
and to execute 'addIceCandidate' task on the queue. If local track
addition is not bundled with initial offer it will often happen that ICE
candidates are queued, before the offer/answer which is queued only once
the local tracks task is done.

* ref(JSPC): use queue for ICE candidates

Refactors the code to get rid of 'delayedIceCandidates' buffer and
use the modification queue to synchronise with the initial offer/answer.

* doc(JingleSessionPC): improve docs

* ref(p2p): use SDP 'inactive' for JVB

This commit gets rid of detach/attach logic and
replaces it with SDP media direction modification.
Now after switching to P2P instead of detaching local
tracks from the JVB peerconnection only the media direction
will be changed to 'inactive'. This will suspend media
transfer on the JVB connection.

It's meant to mitigate Chrome issue where it would randomly
choose to stop sending audio stream, after we modify it's
local SSRC.

* ref(SdpConsistency): cleanup 'recvonly'

Checking on 'recvonly' is no longer reliable way for detecting
whether video media is recvonly, because it can be set to
'inactive' at any point.

Added a check to make sure that the recvonly SSRC is not generated
more than once from '_createOfferOrAnswer'.

* log TPC instance

Logs the TraceablePeerConnection from LocalSdpMunger and
SdpConsistency as part of log messages. Given that there can be
2 TPCs at the same time it was hard to tell for which connection
a log message was printed.

* fix(SdpConsistency): depend on 'recvonly' direction

When createAnswer/createOffer returns SDP it will contain 'recvonly'
direction to reflect current media stream state even though we set
it to 'sendrecv' previously. Using 'hasAnyTracksOfType(VIDEO)' can
not be used to reliably detect 'recvonly' direction when doing video
mute, because muted video track is still in the TPC's map.

* doc(LocalSdpMunger): update description

LocalSdpMunger is currently used only for muted local video tracks.

* fix(P2P): enable P2P on Firefox

After 'detach/attach' is gone it seems that P2P works fine with Firefox.

* ref(TPC): simplify expression

* ref(SdpConsistency): do not pass whole TPC

There's no need to pass whole TPC instance if the only thing needed is
a logging prefix.