Understanding the design of Jitsi

When I learn Webrtc, I see below chart :

I want to match it with the design of Jitsi
is the jicofo the signaling server ? is the jvb the turn server ?

jicofo respond to exchange the SDP between users and allocate a JVB channel ?

Jicofo is the signalling focus and is in the cloud in your graphic. JVB is an intelligent relay server, measuring available bandwidth for clients to decide which stream to relay based on that or what the client is watching or whether to switch off some streams due to limitations of bandwidth.
The line between the nats is only available in p2p mode, and is not always possible, in that mode a simple relay server may be used



the Focus will assign a focus user when a meeting room start as a super user ? the meeting room will use this focus user to exchange with prosody and jvb ?

I am trying to understand the communication between jicofo, prosody and jvb when a video meeting start.
I have some question about the from/to value in the iq request.
to=‘focus@auth.meet.pangu.com/focus2125983216515’ from=‘conference.meet.pangu.com

to=‘focus@auth.meet.pangu.com/focus2125983216515’ from=‘mymeet@conference.meet.pangu.com/focus’

conference.meet.pangu.com is the muc component on prosody ?

'focus@auth.meet.pangu.com/focus2125983216515 what’s this ?

mymeet@conference.meet.pangu.com/focus represent the user focus in meeting “mymeet” on muc server conference

The jicofo user xmpp connection.


I don’t understand here.

Jicofo is the name of the component which is the signalling focus. It has two connections to the xmpp server, as a component and as a user. A simple network diagram: https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md#network-description

So the clients send an iq to jicofo’s component address, hey I want to join a conference and waits for response. Jicofo checks, is there such room: no, then jicofo uses its client connection to create the room, and join it (this is the focus@auth connection and joins as roomname@conference…/focus).
Then it replies to the client, hey you can join, same happens if the room exists.

When jicofo receives a notification that a second user had joined, it opens channels to jvb, creates invites and invites both clients.

You can enable xmpp debug and follow all the xmpp messages that jicofo exchanges:

so the port 5222 is used as a user ?
like focus@auth.meet.pangu.com:5222/focus24649600925147 ?

below presence message: the user focus in meeting room 2a4 send message to prosody via the connection focus24649600925147 ?
focus@auth.meet.pangu.com/focus24649600925147’ from=‘2a4@conference.meet.pangu.com/focus’

These are all user connections, 5222 is the standard xmpp port for that. The component connection is when messages are to or from focus.meet.pangu.com address, without resource.

ok I got your point.

one question about JVB.

the JVB is using colibri to relay streams ? ?

the idea is to create a conference on JVB. add all the participants as endpoints via colibri and colibri will automatically relay the streams to all the participants?
from the log I see neomedia is handling the package. is JVB also using neomedia ?

Colibri is the signalling protocol, used between jicofo and jvb.

Yes, jvb is the one relaying the streams and beeing intelligent of stopping streams if the participant has not enough bandwidth …

Neomedia is used in the old bridge, which binary is still the default for jitsi-meet. This library is handling the media part. In the new bridge which soon will become the default one, which code is in jvb repo in master does not use that library at all.

thanks for the explain.

how does the JVB work as a relay server ? using any framework ?

Nope, it is developed by jitsi.
Once it was just part of the media stack of Jitsi Desktop client, for audio conferences and video calls, then we saw the upload on client machines is not enough to host conferences, especially video. And then was videobridge born when we extracted a server component out of the Jitsi Desktop client.
But recently the bridge media part was re-written and we are currently doing step by step roll out of the bridge to meet.jit.si while monitoring it and once we are confident we will move and jitsi-meet to depend on jvb2.

wow. that’s very cool !
I will learn that code!