Multiregion architecture - Confusing diagrams

Hi there,
I’m confused trying to work out what server architecture would be best to have a single conference with participants from two different regions (say UK and Singapore).
In this post: Understanding OCTO
there was this diagram:

…and @damencho went on to say that this architecture “isn’t supported”.
But in Boris’s article about SFU Cascading ( there is this diagram:

…which appears to be exactly that architecture.
So my questions are:

  1. Should I have a “quick install” jitsi-meet front end server (with jicofo) in both UK and Singapore regions? Or do all participants need to connect to the same front-end?
  2. Do the clients/browsers connect to the JVB directly? I still can’t figure that one out without opening up wireshark and trying to find out manually. The Network Diagram here seems to suggest that port 4443/10000 are open to the outside world for the client to connect to, but other diagrams suggest that video traffic travels via the frontend/signalling server and then to the JVB.

Basically I think it feels like if there is only one server with jitsi-meet/jicofo installed and all traffic travels via that server then I don’t see how having the JVBs themselves (behind the single signalling server) in different regions will have a shorter distance to travel. E.g. A client in Singapore would still be sending/receiving via the primary frontend server in UK. It might then be using a JVB in Signapore, but the client doesn’t connect directly to that in any way, or do they?

Many thanks for any clues. I think I’m missing a small piece of the puzzle.

Yes. They do. The Jitsi Meet server (with Jicofo and Prosody) tells them which Videobridge to use for their conference, based on the region they provided.

Then a direct connection is attempted with the Videobridge (that’s what STUN/TURN/Ice is about. This happens after 2 participants join, 3 if p2p is enabled). The audio/video traffic flows over UDP port 10000 directly from the user’s browser/app to the Videobridge. Meanwhile, there is also some small amount of TCP traffic (http-bind) on port 443 to the Jitsi Meet server. Both happen throughout the entire conference.

There is another good discussion here that may give you more information:

Ah, OK. I think I get it now. The direct communication to the JVB was something I was missing. So with regards to the diagrams… I think the confusion I was having was because you can have multiple shards, but clients must connect to the same shard for a call. Hence the first diagram is “not supported” for per conference. But I suppose having JMS/shards in different regions would be good for resilience, with the right routing.

Many thanks for your reply @corby.

So I now need to work out how I can use the geolocation based route53 routing to different CNAMEs/subdomains on my primary jitsi meet server. I have set up multiple virtual hosts on there already. Ideally I guess you’d want to direct clients to a different subdomain on the jitsi-meet server based on their best latency to a JVB? But that doesn’t sound possible…

Hi @corby @damencho

The first diagram is what I’m trying to implement. I’ve done it mostly and made them autoscalable based upon CPU load.

One questions - How to make additional JVBs to connect both the regions (their own region Region A and Region B) ?

Looking for your quick help.