OCTO config help

Hi Jitsi community,

We are attempting to set up JVB’s in 4 global AWS datacenters with OCTO and High Availability. We are having a bit of trouble configuring OCTO part.

Would someone be interested to jump on a live call and troubleshoot with us?

Happy to pay for your time.


Hi Daryl,

I can’t commit to attend a call right now, but if you describe where you’re at and what the problem looks like I’ll take a look.


Hi Boris,

I hope you’re doing well.

Basically our biggest challenge is how to get GeoLocation done at HAProxy layer considering that we need a GeoIP Database integration.

Beside that how two different shards can communicate, assuming that first shard is in the US with two servers "Jitsi Meet and JVB installed on a separate machine and a second shard is located on eu-west with similar setup.

If a meeting was created on US shard and then a user is trying to join the same meeting from UK through the EU shard then how HAProxy will detect that this meeting was initiated at the US shard and that this request should be directed to the US shard instead of the nearest shard which is EU ?

Below you can find a screenshot demonstrating what I am was trying to describe above

One the above screenshot meeting was created at SA shard then when someone tried to join from the UK then he was directed to the SA shard but he landed into the UK JVB.

One last question, is it possible to override the Backend deployment Info with realtime location information retrieved at client side using any API ? the reason why I am asking is that if this is doable and if this is something you guys might recommend then it will make it easier for us to implement the Geo Location with no need for the extra HAProxy changes you guys have done.

Best Regards,
Mohamed Abada

Hi @Boris_Grozev did you have a chance to think about Mohamed’s response here? Many thanks Daryl

Hi Mohamed,

In our architecture what you are describing is achieved with two separate, independent mechanisms. I recommend you think about and implement them separately as well.

The first mechanism allows conferences to be split among multiple shards (i.e. jicofo instances). We implement this purely on the HTTP level, and this does NOT require clients to know their region. We have a set of HAProxy instances with a shared table mapping a conference name to a backend shard. The proxies are configured to

  1. Route requests to the specified shard if an entry exists in the table

  2. Route requests for new conferences to a specific local backend, and update the table when the conference name is not in the table.

All HTTP requests which are specific for a room (i.e. requests to the BOSH endpoint /http-bind) coming from jitsi-meet clients add the name of the conference as a URL param:
Request URL:


I think a lot of this is described in Yasen’s tutorial here: https://jitsi.org/news/tutorial-video-how-to-load-balance-jitsi-meet/

The second mechanism allows a single conference to be distributed to multiple videobridge instances according to the clients’ regions. This is where clients’ js code needs to know their local region. There are many different ways to implement this. We do it by adding an additional request header, specifying the region of the HAProxy handling the request (which is also the client region) to requests for /config. The server handling the request then replaces the userRegion value in the server file with the header value (using Server Side Includes, IIRC).

I think it makes sense to abstract this in jitsi-meet to allow other implementations, so contributions are welcome. We opted to do it this way because it avoids adding extra initial delay while sending a request to a separate service.

I hope this helps,


Thank you Boris, I’ll discuss this with Mohamed.