Semantic Coherence: Jitsi – Signal Evidence & AI Readability

[H1] More secure, more flexible, and
completely free video conferencing
Learn more
See it in Action! Start a Meeting

[H2]
Introducing Receiver Audio Subscriptions
October 1, 2025
Jitsi Meet has had support for ReceiverConstraints for video for a long time. Receivers can specify which streams they wish to receive, and at what resolutions, and the backend will attempt to satisfy these constraints […]
Read more

[H2]
GSoC 2025, let’s do this!
February 28, 2025
We’re excited to share that Jitsi has been accepted into Google Summer of Code 2025! This is a great opportunity to get hands-on experience, collaborate with our awesome community, and contribute to the Jitsi open-source […]
Read more

[H2]
Connecting anything to everything via SIP
May 21, 2024
In the evolving landscape of virtual meetings, seamless connectivity remains paramount. SIP integration enables participants to join meetings from various devices, including hardware phones or softphones such as Bria, video conferencing systems such as Zoom, […]
Read more

Read all Blog articles

The Tor Project @torproject
If you want an alternative to Zoom: try Jitsi Meet. It’s encrypted, open source, and you don’t need an account. Meet Jitsi.

tmcnet.com @tmcnet
Italian Schools Using WeSchool Platform Based on 8×8’s Jitsi for Distance Learning.

LangSciPress @LangSciPress
Somewhat unexpected, but we now run our own videoconferencing software, #Jitsi It is 100% privacy friendly, 100% open source and runs on our own servers.

[H2] Who is using Jitsi?

[H2] Download Jitsi today.

App Store
Google Play
F-Droid

[H2] Frequently Asked Questions

Read More

[H2] Ask the Community

Check It Out

Blog
[H1] Introducing Receiver Audio Subscriptions

Published on: October 1, 2025 by Kota YatagaiCategories: Featured | GSoC | Jitsi Videobridge | New Feature

Jitsi Meet has had support for ReceiverConstraints for video for a long time. Receivers can specify which streams they wish to receive, and at what resolutions, and the backend will attempt to satisfy these constraints subject to the available bandwidth. But the same flexibility was not available for audio — clients always receive all available audio sources. Until now.
This project, implemented as part of GSoC 2025, introduces the ability for receivers to specify which audio sources they wish to receive.
What can we build with this API? Here are some ideas we’re had, but we’re also excited to see what the community comes up with:
Breakout rooms without entirely separate meetings
Deafen
Live-translated meetings (multilingual webinars)
In the rest of this post we describe how audio subscriptions are implemented and what challenges we faced.
[H2] Signaling message semantics
At the heart of this project is a new signaling message: ReceiverAudioSubscription. This message expresses which audio sources a participant wishes to receive from the bridge. It has two fields:
type ReceiverAudioSubscription = {
mode: "All" | "None" | "Include" | "Exclude";
list?: string[];
};
All – subscribe to every audio source
None – do not receive any audio
Include – receive only the sources listed in list
Exclude – receive all except the sources listed in list
The list field is relevant only for Include and Exclude. By default, every participant is in All mode, which means that unless a subscription message is sent, all audio sources are forwarded (preserving the old behavior). For example:
{ "colibriClass": "ReceiverAudioSubscription", "mode": "All" }
{ "colibriClass": "ReceiverAudioSubscription", "mode": "Include", "list": ["alice-a0", "bob-a0"] }
This message format defines the contract between clients and the Videobridge: clients describe what they want, and the bridge enforces it.
[H2] Client support
On the client side, support for audio subscriptions was added in lib-jitsi-meet PR #2869. Applications can now send ReceiverAudioSubscription messages via simple API calls. The main entry point is:
conference.setAudioSubscriptionMode({
mode: "Include",
list: ["alice-a0", "bob-a0"]
});
This instructs the bridge to forward only the streams from Alice and Bob to the local client. For convenience, there is also a higher-level method for the deafen feature:
conference.muteRemoteAudio(true); // equivalent to { mode: "None" }
conference.muteRemoteAudio(false); // equivalent to { mode: "All" }
Internally, lib-jitsi-meet translates these calls into JSON messages sent over the bridge channel. If Include or Exclude is called with an empty list, the client library automatically coerces the request to None or All respectively. This avoids sending no-op messages and keeps behavior consistent.
[H2] Backend Support
On the backend, Jitsi Videobridge receives the ReceiverAudioSubscription messages and enforces them. Each conference has an AudioSubscriptionManager, which tracks the subscriptions for all participants. For every incoming RTP packet, it decides which participants should receive it based on their current subscription mode.
[H3] Subscription Management in Jitsi Videobridge
Within the Videobridge, each conference has a dedicated AudioSubscriptionManager. This class maintains the subscriptions for all participants and decides, for each incoming packet, which participants should receive it and which should not.
The above sounds straightforward, but in practice there were two main challenges: co-existing with the route-loudest-only option, and handling multi-bridge and mesh scenarios.
[H3] Co-existing with route-loudest-only
Videobridge has a configuration option called route-loudest-only. When enabled, it forwards only the three loudest audio sources. This filtering happens early in the packet pipeline, before any other processing. To coexist with this setting, Videobridge ensures that explicitly subscribed sources are always forwarded, regardless of their loudness. For example, in a breakout room scenario, participants must still hear each other even if none of them are among the loudest speakers. Without special handling, route-loudest-only=true would discard these streams before the subscription logic could act. To solve this, the pre-decrypt loudness check was extended to also verify whether any participant has explicitly subscribed to the source. Because this check runs on every incoming packet, it must be highly efficient. To achieve this, the AudioSubscriptionManager keeps a pre-computed set of explicitly subscribed sources, allowing constant-time checks during packet processing.
[H3] Multi-Bridge Conferences
In large conferences, Jitsi Meet often deploys multiple Videobridge servers connected in a mesh. A participant connected to one bridge may subscribe to a source hosted on another bridge (“remote source”). However, subscriptions are not automatically propagated across bridges.
To address this, we introduce two new inter-bridge signaling messages: AddAudioSubscription and RemoveAudioSubscription.
When a participant subscribes to a remote source, the first subscription on that bridge triggers an AddAudioSubscription message to the bridge that owns the source.
Conversely, when the last subscription to a remote source is removed, a RemoveAudioSubscription is sent.
This ensures that the subscription state is propagated across the mesh with minimal signaling overhead. The same mechanism applies to “Receiver” endpoints—endpoints that do not send media themselves but only receive streams (see this post for the details). When a bridge receives an AddAudioSubscription, it first checks whether the source belongs to one of its directly connected participants. If yes, it updates its AudioSubscriptionManager; if not, it forwards the message toward the bridge that might host the source. This propagation allows subscriptions from Receiver endpoints, even those not directly connected in the mesh, to reach the correct bridge.
[H2] Wrapping up
With this new subscription model, clients can now choose which audio sources to receive, in a similar way they already could for video. The feature supports use cases like breakout rooms, deafen, and selective forwarding in large conferences. The API will soon be available on the server side too, so you can build custom features on top of it.
Share this!

Blog
[H1] GSoC 2025, let’s do this!

Published on: February 28, 2025 by Mihaela DumitruCategories: Featured | GSoC | Jitsi Community

We’re excited to share that Jitsi has been accepted into Google Summer of Code 2025! This is a great opportunity to get hands-on experience, collaborate with our awesome community, and contribute to the Jitsi open-source ecosystem.
If you’re interested in participating, check out our idea tracker for some inspiration. If you have your own cool project idea, we’d love to hear it!
To get started, make sure to check out the following resources:
Jitsi GitHub
Jitsi Handbook
Jitsi Community Forum
The deadline for applications is April 8th, 2025, so be sure to get your proposal in before then! We’re here to support you throughout the process, and we can’t wait to see what you’ll bring to the table.
Stay tuned for updates, join the community discussions, and let’s make GSoC 2025 amazing!
Share this!

Blog
[H1] Connecting anything to everything via SIP

Published on: May 21, 2024 by Oana IancCategories: Featured | Jitsi as a Service | Jitsi Meet | Video Conferencing

In the evolving landscape of virtual meetings, seamless connectivity remains paramount. SIP integration enables participants to join meetings from various devices, including hardware phones or softphones such as Bria, video conferencing systems such as Zoom, and traditional telephony systems. This broadens the scope of participants who can connect to Jitsi conferences, making it more inclusive.
[H2] Leveraging SIP for Video and Audio Connectivity
[H3] Prerequisites
JaaS Account: Create a JaaS account
Host this sample code on your server
Zoom Account: Ensure you have Room System enabled in Zoom
Note: We are using JaaS here for the purpose of simplicity, but all of this can be deployed using the Open Source components available on GitHub.
[H3] Step-by-Step Guide
Join a Jitsi conference on your hosted instance
Get the SIP Addresses for Dial-In
Users can dial into Jitsi conferences from any hard SIP device or Zoom by using the following SIP addresses:
For a combined audio and video experience: pinCode@8×8.vc or [email protected]×8.vc
For audio only: [email protected]×8.vc
Note: Replace pinCode with the specific conference PIN provided for your Jitsi conference
Join a Zoom conference
To connect a Zoom conference to a Jitsi conference, use the Invite via Room System option in Zoom to call out to the provided SIP address
Testing:
Test the configuration by dialing the SIP address. Verify that the call connects to the Jitsi conference and that audio and video is properly routed.
[H2] SIP Audio-Only Connectivity: Cost-Effective and Reliable
SIP audio-only connectivity provides a cost-effective and reliable way for participants to join Jitsi conferences. It reduces bandwidth consumption and costs, making it ideal in scenarios where video isn’t really needed, such as webinars. This option ensures users with limited internet access or slower connections can participate without interruptions.
[H2] Under the Hood: Exploring the Technical Details
Integrating Voximplant with Jitsi Meet involves several key steps:
Setting Up Voximplant Application:
Create a Voximplant application and configure it with the necessary call handling logic. This involves setting up a scenario for incoming calls, managing call routing, and defining custom IVRs
Add logic in the scenario to validate the conference, select a SIP-Jibri and then forward the call to it
Configuring SIP Video Gateways:
Configure SIP Jibris. Refer to the Jitsi SIP Video Gateway documentation for detailed setup instructions
Run a pool of SIP Jibris and use the SIP Jibri selector to select an available SIP Jibri
Setting up a sip domain (Eg. video.8×8.vc):
Define a sip domain and ask VoxImplant to map it to your VoxImplant application
Testing:
One easy way to test the integration is using a softphone to dial in
Note: Voximplant can be replaced with a programmable SIP server such as Kamailio or OpenSIPS.
[H2] Wrapping up
While SIP is these days referred to as legacy, it remains the most used protocol for VoIP and acts as the common denominator across many vendors in the industry. Thus it’s a great candiate for connecting anything to everything ?
❤️ Your personal meetings team.
Share this!