feat(tpc): enforce preferh264 when setting the local description
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.
ref(JitsiLocalTrack): get rid of 'setMutedInProgress'
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).
Random coding style-related issues that bothered me while reading the
source code touched by "Fix local video disappearing from local
thumbnail" (https://github.com/jitsi/lib-jitsi-meet/pull/571). These
include naming, formatting, comments, typos, duplication.
Commit "fix(JitsiLocalTrack): restore 'inMuteOrUnmuteProgress'" removed
all read occurrences of dontFireRemoveEvent so the one and only write
left is now obsolete.
fix(local tracks): do not fire "track stopped" during mute
Flag 'dontFireRemoveEvent' was unreliable, because if
the JitsiLocalTrack is muted/unmuted rapidly it's state can be false
at the time when ended event is triggered. The event handlers must be
unregistered to handle this gracefully.
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.
As new use case for joining a conference without calling GUM has been
added to jitsi-meet enumerate devices should not be delayed. In fact not
only it was delayed, but never called in such case
(getUserMediaStatus.initialized stays false forever).
make audio processing constraints configurable (#491)
* make audio processing constraints configurable
AP: echoCancellation is a "master switch" for disabling all audio processing. set to disableAP=true and stereo=true allows fullband, stereo sound.
AGC: misbehaves with certain 'pre-gained' mics.
HPF: can't hear any effect but it's the last constraint to make configurable.
* Update RTCUtils.js
firefox 54 crashes if we insert the rid simulcast receive lines in the remote description, so only do that if simulcast is turned on (which is still experimental for firefox and not enabled by default)
* 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
feat(ScreenObtainer): trigger external for not verified site
Will trigger external installation also for sites that are not the main
whitelisted domain. This allows to reuse one extension for many sites
(they still have to be on the whitelist, but only one can be "main").
CHROME_EXTENSION_USER_GESTURE_REQUIRED will be triggered if
the extension installation fails, because the request to get desktop
stream did not originate in user gesture handler (a button click for
example).
fix(JingleSessionPC): avoid failures if replaceTrack runs late
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.