# How Jitsi works: follow one meeting through its components

> Think of a Jitsi call as three jobs: load the meeting app, coordinate who joins, and carry the participants' media. The browser client, signaling service, conference coordinator and videobridge do different work. A working page does not prove a working call. Use the checks below to identify the failing stage before changing server settings. [S1][S2]

Source: https://jitsi.help/guides/jitsi-architecture-explained/
Updated: October 30, 2026
Publisher: Jitsi Help (https://jitsi.help/)

## Start with the meeting, not the acronyms

Imagine three colleagues testing a new private meeting server. The first sees the meeting page. The second joins and can speak. When the third joins, nobody can hear the others. Those observations are useful, but they do not identify one faulty component by themselves.

We will follow that fictional example to separate **page delivery**, **signaling** and **media**. This is an original teaching scenario, not an incident or meeting we tested. Component roles follow the official architecture; the P2P example was checked against Meet 11248, commit `f765042`, on 30 October 2026. [S1][S3]

## Know which Jitsi you are using

**Jitsi Meet** is software. **meet.jit.si** is a public service using it. A private deployment has its own operator, configuration and access rules. Embedding an existing service in your app is another choice; it does not automatically make your app the owner of that service. [S1][S5]

For example, the public service's room-creation authentication policy and 95-minute limit are service policies. Do not apply them automatically to every private server. Use the [joining guide](/guides/join-or-start-jitsi-meeting/) for attendee steps and the [hosting cost guide](/guides/jitsi-self-hosting-cost/) when choosing who operates the system. [S5]

## The components in plain English

| Component | Job in this learning model | Useful distinction |
| --- | --- | --- |
| Meeting web app | Shows controls and runs the browser meeting client | Seeing buttons is not proof that remote media arrives. [S1] |
| Web server | Delivers the browser-facing site and associated endpoints | In the reviewed Docker release, this is the `web` service. [S4] |
| Prosody | Provides the XMPP signaling service | Meeting coordination messages are different from microphone audio. [S1] |
| Jicofo | Coordinates conference media sessions and bridge allocation | It is not the media router itself. [S2] |
| Jitsi Videobridge, or JVB | Routes conference media | It is the bridge part of a bridged call. [S2] |
| Jibri | Adds recording or broadcasting workflows | It is an additional service with separate requirements. [S1] |
| Jigasi | Connects SIP audio clients to a conference | Phone integration is separate from ordinary browser joining. [S1] |

## An original map of the three jobs

```text
PAGE DELIVERY
Browser <------ HTTPS ------> Meeting web service

SIGNALING AND COORDINATION (simplified)
Browser <------ signaling ------> Prosody <------> Jicofo

MEDIA WHEN THE BRIDGE PATH IS USED
Browser A <------> Jitsi Videobridge <------> Browser B / C

POSSIBLE TWO-PERSON MEDIA PATH
Browser A <------ peer-to-peer, if enabled and successful ------> Browser B
```

Read the lines as different responsibilities, not a complete packet trace. They omit intermediaries, internal links, optional relays and clustered deployment details. The media line does not mean audio passes through Prosody or Jicofo. The conditional P2P line does not mean every two-person call uses a direct connection. [S1][S2][S3]

## Follow one meeting, step by step

### Step 1: load the meeting application

**Why:** the browser first needs a usable application before you can meaningfully test joining.

**Do:** open the intended server's trusted HTTPS address. Confirm that you are on the correct service and that the page renders. On a private server, use its actual hostname, not a lookalike public-service URL. The reviewed Docker distribution supplies the `web` component alongside the other core services. [S4]

**Check:** the expected page appears without a certificate warning. This establishes page delivery only.

**If it fails:** start with [HTTPS setup](/guides/jitsi-lets-encrypt-ssl/) or the [reverse-proxy owner](/guides/jitsi-behind-reverse-proxy/). Do not bypass a certificate warning to call the installation verified.

### Step 2: join and observe coordination

**Why:** receiving a page and entering a conference are different stages. Prosody and Jicofo have signaling and coordination roles. [S1][S2]

**Do:** use an authorized test meeting and ask a consenting second attendee to join. Record whether both see the intended conference and the other participant, and note any login or admission message.

**Check:** the intended participants arrive in the intended meeting. A local camera preview alone does not establish this result.

**If it fails:** use the [login and moderator guide](/guides/jitsi-login-moderator-password/) or [session-expiry diagnostics](/troubleshooting/jitsi-authentication-session-expired/). Do not diagnose Prosody from one generic connection message without further evidence.

### Step 3: verify media in both directions

**Why:** a successful roster or local preview does not prove that the other person receives your voice or video.

**Do:** ask each attendee to speak in turn and confirm reception. Check the selected devices and ordinary mute/moderation state separately.

**Check:** each side receives the expected media. If only local preview works, preserve that observation rather than calling the entire call successful.

**If it fails:** start with [device permissions](/troubleshooting/jitsi-camera-microphone-not-working/) or [one-way audio](/troubleshooting/one-to-one-calls-fail-one-way-audio/), according to the symptom.

### Step 4: include a third participant and the required networks

**Why:** the reviewed configuration tries P2P for exactly two participants when enabled. If it succeeds, media can leave the JVB path; a third participant moves the conference back to the bridge. [S3]

**Do:** add a consenting third participant and repeat the same reception checks across the networks the service must support.

**Check:** record whether media still works and when a failure starts. Three attendees are a useful functional check, not a capacity benchmark or proof of every network path.

**If it fails:** follow [three-participant and bridge diagnostics](/troubleshooting/jitsi-video-not-working-3-participants/). Compare configuration, network reachability and logs before changing several settings. The timing is a clue, not proof that one port is the cause.

## Choose the next task

| Your task | Continue here |
| --- | --- |
| Build a fresh private server | [Docker installation](/guides/install-jitsi-docker/) or the separate [package recipe](/guides/install-jitsi-ubuntu/) |
| Put an existing service inside your app | [IFrame API integration](/guides/embed-jitsi-iframe-api/) |
| Record or broadcast meetings | [Jibri recording](/guides/jitsi-recording-jibri/) |
| Understand encryption and its boundaries | [Transport versus media E2EE](/guides/jitsi-end-to-end-encryption/) |
| Estimate deployment size | [Server requirements](/guides/jitsi-server-requirements/) and [capacity calculator](/tools/jitsi-server-size-calculator/) |

You do not need to memorize every setting before your first investigation. Keep a small record: server/build, symptom, participant count, networks tested and what passed at each stage. Remove private meeting names, links, tokens and credentials before sharing it.

## Sources, verification and maintenance

- **[S1]** [Official architecture overview](https://jitsi.github.io/handbook/docs/architecture/), checked 30 October 2026: component model. The diagram and fictional walkthrough above are our own simplified explanation.
- **[S2]** Official [Jicofo](https://github.com/jitsi/jicofo) and [Jitsi Videobridge](https://github.com/jitsi/jitsi-videobridge) project documentation, checked 30 October 2026: coordination versus media routing.
- **[S3]** [Meet 11248 configuration](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/config.js), `p2p` section: conditional two-person behavior, not a guarantee about every deployment.
- **[S4]** [Docker stable-11248-2 Compose](https://github.com/jitsi/docker-jitsi-meet/blob/74d3e6edbb275d700d25de71bddc7088a78b1af4/docker-compose.yml): core service separation.
- **[S5]** Official [authentication policy](https://jitsi.org/blog/authentication-on-meet-jit-si/), 22 August 2023, and [public-service time limit](https://jitsi.org/blog/changes-coming/), 9 October 2026. These describe meet.jit.si policies, not every deployment's configuration.

No real meeting, packet capture, media route or server test was performed for this guide. The diagnostic sequence is a recommendation; source review is not an observed production result. Recheck after component, P2P/default, service-policy or deployment changes. Open questions for your system are which build is served, which routes were negotiated and which networks the acceptance test must cover.

## Frequently asked questions

### Are Jicofo and the videobridge the same thing?

No. Jicofo coordinates conference media sessions and bridge selection. Jitsi Videobridge routes media. Investigating conference coordination and investigating the media path are related but different tasks.

### Does a working two-person call prove my Jitsi server is ready?

No. In the reviewed client, an enabled and successful peer-to-peer connection can carry a two-person call without using the bridge media path. Test three participants across the networks you need, and inspect the actual route and symptoms.

### Do I need Jibri and Jigasi for every Jitsi meeting?

No. They serve additional workflows: Jibri handles recording or broadcasting, while Jigasi can connect SIP audio callers. Installing either is a separate project, not a prerequisite for understanding a normal browser meeting.

### Does this diagram show every possible Jitsi deployment?

No. It is a simplified learning model. Peer-to-peer mode, relays, multiple bridges, visitor systems and optional services can change the real route. Verify the deployed configuration before applying a diagnosis.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.