feat(xmpp): trigger CONNECTION_FAILED when closed unintentionally
If Strophe drops the connection while not being asked to, it means that
most likely some serious error has occurred. One currently known case is
when a BOSH request fails for more than 4 times then the connection is
dropped without supplying a reason through the Strophe API
(the connection status simply goes to DISCONNECTED).
fix(ParticipantConnStatus): get in sync with JVB status
When the remote track which caused to transit to the disconnected status
is removed from the conference the current status received through
the data channels should be used to avoid getting out of sync by missing
"muted"/"unmuted" events sequence.
Usually the track removed is replaced by the new one(in our use cases),
but the new track is always added unmuted. Now if the connection gets
restored in the meantime while the track is being signalled then
the 'muted/unmuted' event sequence may be missed and the participant
might be blocked in the "disconnected" state forever.
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.
Lib-jitsi-meet uses Temasys on Internet Explorer and Safari so it does
not make sense to require its adapter.screenshare.js on React Native,
for example, where it fails anyway.
I added reporting of Promise's reject reason in b10a1fc while merging
jitsi/ss_postinstall_fix since Promise's reject function has such an
argument. Hristo Terezov disagreed with it because reason is undefined
in the use case and found it to be confusing so I'm reverting to what he
intended in the first place.
Simplify the source code by using some ES6 features such as arrow
functions to avoid the use of 'var self = this', the shorthand for
method definitions in object initializers.
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.
As I see no hidden meaning in the current non-preservation of
alphabetical order, I prefer to facilitate scanning (in the fashion of
searching in a dictionary).
Fire conference_left only if it is not a kick presence unavailable.
When we receive kick presence it is both 110 and 307 status code, so we were triggering both conference_left and kicked event. Now when we receive kick we process as it is 110 to clean participants and room and then fire the kick event.