Jitsi Meet connection phases - pvgupta24/Jitsi-Meet-Concepts GitHub Wiki

Tools for analyzing the time taken by the different stages during initialization

  • We measured most of the connection events and triggers using the javascript clock (window.performance.now()) and the network tab in the browser developer tools which gives the relative time of trigger if the particular event with respect to the time of launching the application.
  • First step included estimating the time taken by different stages based on (TIME) tagged logs of the different triggers in the conference.

Understanding the stages

Jitsi-Meet involves many layers (but that also makes it interesting). Layers and Components in a Jitsi Video Conference

The main components and stages involved along with the time measurements (in ms) are:

HTML, Configurations and Application Bundling

This includes loading of following files

  • index.html
  • config.js
  • bundle files

(TIME) index.html loaded: 614.6999999982654

The time taken for the index.html to load on the browser.

(TIME) Sending external connect XHR: 619.299999998475

The time at which the AJAX request is sent to the webservice for creating the BOSH sessions on the server machine where the XMPP server is also deployed. This provides for a faster way for creating a BOSH session by attaching the client with the connection which was opened on the server and whose configuration (jid, rid, sid and password) was attached with the Strophe (client) as compared to initiating a BOSH session directly from the .

[react/index.web.js] <HTMLDocument.>: (TIME) document ready: 1213.8000000013562 DOM elements are loaded and other modules (react etc.) can be injected wherever required (TIME) external connect XHR done: 1302.9999999998836

XMPP Connection for sending stanzas

This involves three main concepts:

  • BOSH session
  • XMPP login
  • XMPP MUC - Each conference in Jitsi-Meet has its own MUC

[modules/xmpp/xmpp.js] <t.value>: (TIME) Strophe Attaching :1412.5999999996566

The time at which the BOSH session tries to bind with the Strophe client. This can be a new session initiated on the server or an attempt to connect to an existing one in case the client gets disconnected (By a different requestID: rid = old_rid + 1 ).

[modules/xmpp/xmpp.js] <t.value>: (TIME) Strophe attached: 1413.7999999984459

The time at which the connection status change is triggered (when strophe attaches to an existing BOSH session). If p2p and StunTurn is enabled, an attempt is made to connect to the STUN and TURN servers one after the other in case one fails for sending the media packets directly instead of using the JVB.

[modules/xmpp/ChatRoom.js] <t.value>: (TIME) MUC joined: 2626.0000000002037

The time at which the current user joins the XMPP Multi-User-Chatroom.

WebRTC

This involves understanding many networking concepts like signalling protocol(XMPP), NAT, ICE, STUN, TURN.
WebRTC consists of these five stages:

  • Connect users - using a common url token
  • Start signals - using a signalling protocol like XMPP
  • Find candidates - finding devices behind NAT using ICE(STUN/TURN)
  • Negotiate media sessions - agree on the type of media to be communicated
  • Start RTCPeerConnection streams - start real time communication

The RTCPeerConnection API is the heart of the peer-to-peer connection between each of the WebRTC enabled browsers or peers. The RTCPeerConnection interface represents a WebRTC connection between the local computer and a remote peer. It provides methods to connect to a remote peer, maintain and monitor the connection, and close the connection once it's no longer needed.

RTCPeerConnection contains a property called iceConnectionState which returns the state of the ICE agent associated with the RTCPeerConnection which is an enum of type RTCIceConnectionState. The RTCIceConnectionState enum defines the string constants used to describe the current state of the ICE agent and its connection to the ICE server (that is, the STUN or TURN server). These are the possible string constants.

  • new − the ICE agent is waiting for remote candidates or gathering addresses
  • checking − the ICE agent has been given one or more remote candidates and is checking pairs of local and remote candidates against one another to try to find a compatible match, but has not yet found a pair which will allow the peer connection to be made. It's possible that gathering of candidates is also still underway.
  • connected − a usable pairing of local and remote candidates has been found for all components of the connection, and the connection has been established. It's possible that gathering is still underway, and it's also possible that the ICE agent is still checking candidates against one another looking for a better connection to use.
  • completed − the ICE agent has finished gathering candidates, has checked all pairs against one another, and has found a connection for all components.
  • failed − the ICE agent has checked all the remote candidates but didn't find a match for at least one component.
  • disconnected − at least one component is no longer alive.
  • closed − the ICE agent is closed.

An iceconnectionstatechange event is sent to an RTCPeerConnection object when the state of its ICE connection changes. The new ICE connection state is available in the object's iceConnectionState property.

The RTCPeerConnection.oniceconnectionstatechange property is an event handler which specifies a function to be called when the iceconnectionstatechange event is fired on an RTCPeerConnection instance.

<i.peerconnection.oniceconnectionstatechange>: (TIME) ICE checking P2P? false: 32246.09999999666

The ICE agent has remote candidates, but it has not found a connection yet. The connection is not peer-to-peer.

<i.peerconnection.oniceconnectionstatechange>: (TIME) ICE connected P2P? false: 33492.69999999888

The ICE agent has found a usable connection, but is still checking more remote candidates for better connection. The connection is not peer-to-peer.

<i.peerconnection.oniceconnectionstatechange>: (TIME) ICE checking P2P? true: 36942.49999999738

The ICE agent has remote candidates, but it has not found a connection yet. The connection is peer-to-peer.

<i.peerconnection.oniceconnectionstatechange>: (TIME) ICE connected P2P? true: 37573.199999998906

The ICE agent has found a usable connection, but is still checking more remote candidates for better connection. The connection is peer-to-peer.

<i.peerconnection.oniceconnectionstatechange>: (TIME) ICE completed P2P? true: 53226.39999999956

The ICE agent has found a usable connection and stopped testing remote candidates. The connection is peer-to-peer.

⚠️ **GitHub.com Fallback** ⚠️