Add RFC 4588 to the list of advertised features on Firefox.
Use RtxModifier only for cases when simulcast is achieved through SDP munging
This will ensure that RTX is negotiated whenever it is offered by the browser.
feat(video-quality): control the sender resolution based on video quality settings (#1119)
* 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
fix(unified-plan): use RTCRtpSender.replaceTrack for mute/unmute/replace operations
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
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.
Apply max bitrate of 500Kbps on desktop streams and set the contentHint attribute on the track to 'detail'. (#992)
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.
ref(JitsiConference): move sendTones impl to TPC (#983)
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.
fix(remote-description): remove the default id of "-" (#845)
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.
fix(TPC): ignore "ontrackadded" for existing track
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.
Change layer suspension to use parameters in RTPSender (#786)
* 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
Implements the promised based getStats. Enables them for Safari and FF.
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 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.
fix(ie11): do not call JSON.stringify with temasys ice candidate
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.
Reports ssrc to callstats when screen sharing is started. (#657)
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.
fix(ie11): do not type check for RTCSessionDescription
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.