How Jitsi work

Hi together,

i try to understand deeper how jitsi works.
I understand that the Video-Bridges (VB) publish his status to the Node and Jicofo get this information as a notification and can work with it.

But how Jicofo initialized new conference on the vb?

When i look at the jicofo.log. I finde some interesting informations.

org.jitsi.jicofo.xmpp.FocusComponent.handleConferenceIq().402 Focus request for room: shop@conference.mydomain.ru

org.jitsi.jicofo.FocusManager.log() Created new focus for shop@conference.meeting.oesolution.ru@auth.mydomain.ru conferences count: 1 options:

in the prosody config i found

Component "focus.mydomain.ru"
    component_secret = "XXXX"

and in the jicofo config i found

# sets the username to use for XMPP user logins

JICOFO_AUTH_USER=focus

# sets the password to use for XMPP user logins

JICOFO_AUTH_PASSWORD=XXXXX

So i can reconstruct that jicofo communicate to the component as a focus user to send over xmpp a command to the VB.

But how? Because the VB is only a publisher in xmpp. How the VB get information to create a new conference or something else.

1 Like

So here are the overall steps in the communication between client, jicofo and jvb.

  1. A client connects to the xmpp, and sends an IQ to the jicofo component address.
  2. Jicofo creates a room, joins the room, and make the one who requested to create the room an owner in the room, if he is the first one.
  3. The client receives the succesfull response from jicofo and joins the room.
    Nothing happens, here as there is just one participant.
  4. A second participant joins, jicofo sees that and starts the process of connecting both clients
  • sends an IQ to the jvb component address to allocate channels for both participants.
  • uses the allocated channels data to create jingle session-initiate, which then sends to both clients
  1. Clients accept it and start sending and they are now connected using jvb.

The pubsub you are mentioning is just for jicofo to see available bridges, and how busy are they, so it can balance between them. Jicofo uses the videobridge component address to communicate with it.

Hope this helps.

5 Likes

HI Damian,

that helps! Thank you

All the first communication takes places via XMPP between Jicofo and the VB. The SIP communication will be initialized via XMPP too? With the xmpp jingle extension. Right?

But important to know is. Has the VB an own sip-communicator? Else the communication should be always run over Jicofo (p2p deactivated):
IMG_7183F1CD76A2-1

So I cant imagine that. I think after the initialization the communication should shows like this:

Can you explain what do you mean by ‘sip communication’ and when you say the communication between x and y, what do you mean, signalling or media?

Signalling is always to the xmpp server while media (p2p disabled) is always between client and bridge.

is there any specification describing this process?

1 Like

I agree a specification would be great

1 Like

Hello,
This explanation is good for overall view. But I need a little more explanation to kick off. Is there any internal documentation/explanation especially about jicofo ? Like which modules and channels/relations have which responsibilities ?

@damencho While Googling around, I found this article from 2015. Is any of it still true? Thanks.

Hi, everyone!

Now I’m investigating implementation of Jicofo and Jitsi Video Bridge modules and implementation of WebRTC signaling.

Could anybody clarify a few things about RTP video payloads and basic signaling rules?

To simplify things, let’s suppose only VP8 video codec is enabled.

  1. I’ve discovered that in case of 3 or more participants VP8 payload is always set to 100 for every participant. But when I change jicofo/sip-communicator.properties like below VP8 payload is always 96 :
    org.jitsi.jicofo.VP8_PT=96
  2. From the JitsiMeet client perspective signaling looks like below:
    2.1 JitsiMeet sends focus request to Jicofo:
    2.2 Then JitsiMeet receives from Jicofo ‘ session-initiate ’ response with codec names, payload, SSRC, etc.
    2.3 JitsiMeet converts this data to SDP offer , generates SDP answer , converts the answer to session ‘session-accept’ XMPP response and send it to Jicofo.

So I made the following conclusions.

  1. On WebRTC signaling phase Jicofo always generates SDP offer and JitsiMeet always generates SDP answer .
    Is this correct?
  2. When Jicofo creates a room and allocates media channels it sets payload value to VP8 codec.
    the default value is 100 or other from the configuration.
    If so, all clients joining the conference always have the same VP8 payload value:
    100 (or from config).
    Is this correct?

Please correct me if I have any misunderstanding.

Some more questions:

  1. Are asymmetric RTP payloads supported by Jitsi?
    For example: 2 conference participants have VP8 payload=100 but the third participant VP8 payload is 96.
    Is it possible?

  2. What is use case of “5.2 Updating payload information for a channel” in
    https://xmpp.org/extensions/xep-0340.html ?

Thanks.

1 Like

Damian,

Your explanation about overall steps is quite clear.
Could you also clarify how p2p mode works?

  1. Does this mean that two applications that open the same Jitsi room are first trying to connect via JVB?

  2. Then, in case of success they try p2p connection?

  3. Is it possible to establish p2p connection when JVB is not running?

Thanks.

No, they open two peer connections one for p2p and one to jvb. If p2p one fails they switched to jvb, if third one joins they switch to jvb one if they were using the p2p one.

The default behavior is when jvb is not available you will see a reload screen. A shard is considered unhealthy if there is no jvb, and reload screen is a mechanism to move people to new healthy shard in multi-shard environment.

OK
Thank you for replying