Currently if RTCPeerConnection is closed (an event is delivered) and we haven't called close method ourselves, this means browser has closed it due to suspending the PC.
fix(JingleSessionPC): send SSRC updates regardless of the ICE state
ICE connectivity issues can be transient and those should not prevent
from sending SSRC updates. XMPP stream is a separate connection/stream
and skipping the updates while ICE is disconnected results in broken
media session where the stream information is not propagated correctly
across the conference participants.
Our JSHint configuration is not extensive and we have excluded multiple
files from linting. Additionally, we have seen JSHint to be unable to
parse newer ECMAScript features such as the object spread operator
(proposal).
On the other hand, we have seen ESLint to beautifully work on React and
React Native source code in addition to ES2015 and later. Introduce
ESLint alongside JSHint as an intermediate step to eventually switching
from JSHint to ESLint.
As our source code does not fully follow even the JSHint rules we have,
it is very difficult to introduce ESLint with many rules. At the
beginning, introduce it with as little rules as possible. Morever,
ESLint is able to automatically fix certain rule offenders so once we
have ESLint merged we can incrementally add new rules while keeping our
commits' modification on as little subjects as possible.
When source-add and source-remove for the same SSRC arrive just one after
another, SSRC will not be removed as it didn't make it to the remote description
yet.
Before the change we were constructing lines to be removed based on SSRC
parameters values supplied in the notification. We want the client to simply
remove all lines related to the SSRC being removed as sometimes things get
out of sync. For example when Chrome adds 'default' mslabel or when we'll be
doing lipsync stream merging.