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 for attendee steps and the hosting cost guide 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
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 BRead 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 or the reverse-proxy owner. 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 or session-expiry diagnostics. 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 or 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. 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 or the separate package recipe |
| Put an existing service inside your app | IFrame API integration |
| Record or broadcast meetings | Jibri recording |
| Understand encryption and its boundaries | Transport versus media E2EE |
| Estimate deployment size | Server requirements and capacity 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, checked 30 October 2026: component model. The diagram and fictional walkthrough above are our own simplified explanation.
- [S2] Official Jicofo and Jitsi Videobridge project documentation, checked 30 October 2026: coordination versus media routing.
- [S3] Meet 11248 configuration,
p2psection: conditional two-person behavior, not a guarantee about every deployment. - [S4] Docker stable-11248-2 Compose: core service separation.
- [S5] Official authentication policy, 22 August 2023, and public-service time limit, 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.