Websocket keep alive is HTTP GET request sent on the service URL passed
to Strophe. It is used to keep the stick tables alive. The feature comes
in enabled by default whenever Websocket are used. Pass
'websocketKeepAlive' config option set to -1 to disable.

See the code for more details about the default interval value.

If Strophe goes to the ERROR state it will pass the error message there
and then transition to the DISCONNECTED state, but without any error
msg.

Given that the XMPP connection is able to reconnect after a drop, now
the jingle session needs to hold off any updates that have to be sent
while the signalling is down. Send the update upon reconnect to sync
Jicofo and JVB with the client's source description.

The connected flag is flipped to true as soon as transport connection is
established by Strophe(such as WebSocket TCP), but it doesn't mean that
the connection is ready to send stanzas yet.

All calls to connection.send should go through the wrapper in order to
prevent breaking the connection by calling it in the not connected
state.

This prevents from accessing Strophe internals directly and allows to
block 'send' calls while disconnected. The latter breaks the stream
resume logic by putting stanzas onto the send queue.

TODO make jitsi strophe plugins use the XmppConnection wrapper whenever
possible instead of interacting with the Strophe.Connection directly.

Websocket sends queued presence 'unavailable' and the stream close
message correctly when the connection is being closed.

This way it's easier to figure out which parts of the disconnect method are about
cleaning up the connection and the reasons on why it's important can be put in
the JDoc of this method.

...it make it easier to process the logs in automated way.

It can either be a websocket or bosh URL, so the current naming is
confusing.

We add the capScreenshareBitrate value to the permanent properties so
that it's included with every event that we send to the analytics
backend.

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.

* Fix URL for sendBeacon.

* Performs sendBeacon once or connection.disconnect().

The client will reject P2P session-initiate if the conditions which
allow for P2P session to start are not met(there more or less than 2
human participants in the call).

If DTLS fingerprint remains unchanged after ice-restart there will be no
media flow even thought the ICE connection will be re-established.
That's because JVB has all layers re-initialized from scratch, but
the WebRTC stack will keep the current state of the DTLS layer.

Reset the DTLS layer by setting an all zeros fingerprint on the hacky
offer/answer cycle which is currently done in order to reset the data
channels and the sequence number counters on the RTP receivers.

Move time since last success error detail to
the _getConnectionFailedReasonDetails method and use it on all
connection failed events.

This functionality is being brought back for apps
that use ljm for its prosody logic but not for
video conferencing, ie Jitsi-Meet Spot. The desired
use is for Spot-TVs to be identifiable by their
jid alone and for the resource to be the part
that identifies them.

The version change is invoked from add/remove features which controls whether to submit the presence.

* Always uses 8 hex digits for the MUC nickname/endpoint ID.

* squash: Fix a comment and add the full JID to the log.

* squash: Fixes the compilation and style.

Add 'timeSinceLastSuccess' to the details of connection dropped event.

Also do not execute any peerconnection callbacks like
'oniceconnectionstatechange', 'onicecandidate' etc. after close.

Attempts to fix this race condition:
1. Web client joins a conference.
2. Electron client joins the same conference.
3. Web client requests capabilities of Electron
   using version 1111.
4. Electron adds remote control capability,
   settings its version to 2222.
5. Electron responds to web client's requests
   but with features of 2222.
6. Web client caches request under 1111.
7. Any future calls to get features for a client
   with version 1111 will incorrect include the
   remote control capability.

Attempts to fix the following issue:
1. Electron user starts the conference join process.
2. Electron user adds remote control capability and
   attempts to send presence.
3. Electron user presence send is blocked because the
   conference has not been joined.
4. Electron user joins the conference.
5. The remote control capability is not emitted until
   some other presence change triggers another
   presence send. Until then, other uses will not see
   remote control option available for the electron
   user.