A videobridge in Frankfurt works fine for people in Berlin. For someone joining from Singapore, every packet makes a round trip of around 150 to 200 milliseconds before it reaches the other participants, and they notice. When your users are spread across continents, you want each of them on a bridge close to home.
Jitsi supports this, but not in one switch. There are two separate layers, and people often set up one and expect the other.
| Layer | What it decides | Tools |
|---|---|---|
| 1. Which shard | Which Meet server (web, Prosody, Jicofo) the browser talks to | DNS: Route 53 geolocation or latency routing |
| 2. Which bridge | Which videobridge carries each participant's media | Bridge regions, userRegion, Jicofo's selection strategy, relays |
Layer 1: send users to a nearby shard with Route 53
Run a complete shard in each region, for example one in eu-central-1 and one in ap-southeast-1, and put one DNS name in front of both. Route 53 answers each user with the address of the right shard:
- Latency-based routing picks the AWS region with the lowest measured latency for that user. Our default.
- Geolocation routing picks by the user's country or continent. Use it when data must stay in a region, such as EU users on EU servers.
This was our 2019 approach: a copy of the Jitsi Meet front end per region, each in its own S3 bucket behind CloudFront with its own config.js, and Route 53 geolocation records on the shared domain.
Meetings don't cross shards
Layer 2: put each participant on a nearby videobridge
This is what makes a single meeting work across regions. One shard, with videobridges in several regions, and Jicofo choosing a bridge per participant.
Give each bridge a region
In /etc/jitsi/videobridge/jvb.conf on each bridge, set its region and enable relays, which let bridges in one conference forward media to each other (older docs call this Octo):
videobridge {
relay {
enabled = true
region = "eu-central-1"
relay-id = "jvb-eu-1"
}
}Tell Jicofo to use regions
By default Jicofo keeps each conference on one bridge. Switch its strategy in /etc/jitsi/jicofo/jicofo.conf:
jicofo {
bridge {
selection-strategy = RegionBasedBridgeSelectionStrategy
region-groups = [
["eu-central-1", "eu-west-1"],
["ap-southeast-1", "ap-south-1"]
]
}
}region-groups treats nearby regions as one, so a Paris user can share the Frankfurt bridge already in the call instead of opening a new relay. The options are documented in Jicofo's reference.conf.
Tell each client its region
Here's the part that isn't automatic. Jicofo only knows a participant's region because the client says so, from config.js:
config.deploymentInfo = {
shard: 'shard1',
region: 'eu-central-1',
userRegion: 'ap-southeast-1',
};userRegion has to differ per user, so a single static config.js can't do it. Two ways:
- Regional front ends, as in layer 1: each region's copy of the web app has its own
userRegion, and DNS or CloudFront picks the copy. - Inject it at the edge. Put CloudFront in front, forward the
CloudFront-Viewer-Countryheader, and have nginx map countries to regions and write the value into the config it serves. One front end, no copies to keep in sync.
What you get
A participant in Singapore connects to a Singapore bridge, a participant in Berlin to a Frankfurt bridge, and the two bridges exchange one copy of each stream between them. Each user's link to the bridge is short, which is where most of the jitter and packet loss happened. The long intercontinental hop still exists, but it runs between two data centres on good networks instead of over someone's hotel Wi-Fi.
Make sure UDP traffic between the bridges is allowed in both regions' security groups, or relays silently fail and participants fall back to a distant bridge.
Is it worth the extra servers?
For most teams, no. If 90% of your calls are within one continent, one shard in the right region is simpler, and the few far-away users get a slightly worse experience rather than you running bridges on three continents. Multi-region pays off for global webinars, companies with large offices in several continents, and platforms with users everywhere.
Read load balancing multiple videobridges first, since the same Jicofo settings apply, and scaling videobridges with Octo for relays in more depth. When you size bridges per region, auto scaling Jitsi on AWS keeps idle regions cheap, and Jitsi architecture explains how the components fit together. If you want this built for you, see our Jitsi hosting service on AWS, Azure and GCP.
Frequently Asked Questions
Can Jitsi Meet connect users to the nearest videobridge?
Yes. Give each videobridge a region, tell each client its region through deploymentInfo.userRegion in config.js, and switch Jicofo to RegionBasedBridgeSelectionStrategy. Jicofo then places each participant on a bridge in their own region where one is available.
How does Jitsi know which region a user is in?
It doesn't work it out itself. The client reports the region set in its config. You serve a different config per region, either from regional front ends picked by Route 53 geolocation routing, or by injecting the region from a GeoIP or CloudFront viewer-country header.
What happens when participants from two regions join the same meeting?
With relays (formerly called Octo) enabled, each participant uses a bridge in their region and the bridges forward media to each other. Each person gets a short hop to a nearby server, and only one copy of each stream crosses the long link.
Should I use Route 53 geolocation or latency routing for Jitsi?
Latency-based routing is usually the better default because it measures actual network distance to AWS regions. Geolocation routing suits cases where you must keep users in a country or region for legal reasons.
Is a multi-region Jitsi setup worth it?
Only when participants are regularly far apart, such as Europe and Asia in the same calls. For a team mostly in one region, one well-placed shard is simpler and cheaper, and the latency gain elsewhere is small.
