Jitsi Meet Architecture Description

Hello community,

We are a group of 4 students from TU Delft. Two weeks ago Kylian Kropf spoke in the community meeting about our plan to extend the Jitsi Handbook with a description of the Jitsi architecture. We had hoped to join the community meeting today to discuss our idea. However, we forgot that daylight savings time changes differently in the US than in the EU. I will do that in this post instead.

We extended the current handbook entry on architecture with a graphical overview of the components and context and will extend the text with a high-level explanation of the codebase and testing suites (please note that these sections are bullet points for now and will be explained in more detail.

id: architecture
title: Architecture

In this section, a global overview of the Jitsi infrastructure is provided. If you just started contributing to the project, we highly recommend reading this section thoroughly.


Jitsi comprises a collection of projects:

  • Jitsi Meet - WebRTC compatible JavaScript application that uses Jitsi Videobridge to provide high quality, scalable video conferences. Build upon React and React Native
  • Jitsi Videobridge (jvb) - WebRTC compatible server designed to route video streams amongst participants in a conference
  • Jitsi Conference Focus (jicofo) - server-side focus component used in Jitsi Meet conferences that manages media sessions between each of the participants and the videobridge
  • Jitsi Gateway to SIP (jigasi) - server-side application that allows regular SIP clients to join Jitsi Meet conferences
  • Jitsi Broadcasting Infrastructure (jibri) - set of tools for recording and/or streaming a Jitsi Meet conference that works by launching a Chrome instance rendered in a virtual framebuffer and capturing and encoding the output with ffmpeg

External Software used by Jitsi:

  • Prosody - XMPP server used for signalling

Architecture Diagram

The individual connections between the, previously described, components as well as the external integration’s are described in the figure below.

The external connections can be categorised into two main groups. Firstly, the connections between clients that request a video or audio connection performed through remote requests and data streams. The second category of external connections are those to external services that help store recordings, stream recordings, stream videos or help with creating meetings.

Code Map

./react - Contains the react components for web and mobile.

./modules - High level logic.

./lang - Translations for many languages.

./css - Css of the project.

./resources - Resources that are used throughout the codebase.

./twa Trusted Web Activities used to help with the creation of the android application.


The main form of testing code changes is done manually, for example in the beta test.

Besides that, unit tests can be performed on the Jitsi Meet code base by using the Jitsi Meet Torture project. The project contains automated Maven tests for several key functions such as peer2peer and invites.

Would this be a format adequate for the handbook? Is anything missing or incorrect? We would very much appreciate your feedback

Kind regards,
Kylian, Rembrandt, Nils and Andries



Maybe the videobridge selection strategies and the videobridge scalability options can be added

Awsome, one-note though, jigasi connects to prosody as the normal webclient for signaling and as the normal client sends media stream (audio only) to the jvb.
Also the outlook part is strange … not sure what you want to show with it. Outlook can have events that will hold link to the meeting but by clicking it - it will open web browser with the meeting as you use web-browser, but not connecting to the webserver. The other option while creating the event is to generate room name and contact the conference mapper for the dial-in pin, but that request is to a service which is not shown in the diagram and that service is also used by the webclient to show the the same information and is used by the sip server IVR implementation to convert that pin to a meeting name.
And one more, maybe mentioning that jvb is SFU.
Hope this helps, any questions are welcome and that is great for the handbook.

While writing these comments I realized that if you want to include that in the handbook it will be way easier to create a PR so comments can go directly there, it is what PRs are for - reviews :slight_smile: and of course, you can still add here a link to it so the community can chime in …

1 Like

Given that’s a high level architecture description, details such as the fact that Prosody is also used as a standard meeting server (for chats) can be left out; however, I don’t see what you are meaning by ‘exchange files’ between JVB (possibly your could add this nickname to the jitsi-videobridge ?) and Prosody. IMO it’s Xml messaging also. And a direct connection between Jicofo and JVB seems to be missing (Colibri signaling through REST for statistics most notably). While I’m at it, Jicofo is also a load balancer, it’s a very important feature.

1 Like

Wow, very nice work. Maybe it is useful to add BOSH (http-bind) but i’m not 100% sure where to add it. As far as i understand it is a module to enable XMPP over HTTP and it is module of the prosody?! So i guess there would be one more arrow from web-browser → web server/prosody.

Correct me if i am wrong.

This is already covered, webclients send requests to webserver which then proxy them to prosody as xmpp messages. And this can be websockets or bosh.

For everyone interested, we opened a PR on the matter here:

Great work @ahreurink, this helps us alot!

We are currently setting up a Jitsi deployment and need to understand how the communication flows in order to harden the network. Specifically which component initates the trafic to where.

Your diagram shows bidirectonal communication. Does that mean that communication is initated from both sides in all components? If no, is there somewhere I can read to see the inbound and outbound flows?