I’m trying to configure Multiple JMS [Jicofo + Prosody] server behind a load balancer.
For Load balancer, I m using AWS NLB where I configured two listener 1. TCP 443 and 2. TCP 5222 which is pointing to JMS servers.
Issue Observed :-
1.When user 1 create a meeting e.g. jitsi-url/test123 which schedule on JMS 1 server and when user 2 is trying to join jitsi-url/test123 meeting, we found that when 2nd user hits the URL, It schedule on JMS 2.
And bcoz of that they are not able to be in the same bridge or JMS server.
When I opened Jitsi meeting url in multiple tab of my browser → it is working.
But when trying to join the same meeting from different browser then it is not landing on the same conference call.
Could you please help me on this ? where is the issue ? What I m doing wrong ?
As mentioned in answers ([1], [2]) to you last thread, what’s important is that the routing needs to be sticky based on room name. For example, if user A is the first to join Room123 and is routed to shard 1, then it is imperative that all users joining Room123 must be routed to the same shard.
AFAIK, stickiness in AWS NLB is for sessions (the same user is always routed to the same instances) which is not what is needed here.
This is usually done using HAProxy stick tables. To ensure that there is no single point of failure, you can deploy multiple HAProxy instances fronted by NLB, then have the HAProxy peered so that the stick table is sychronized across the peers. You can find some examples if you search for “stick table” in this forum.
I agree that people mentioned in many places to use HAproxy.
I was trying to find an alternative or looking for a managed service in the cloud provider to handle this.
As adding HAProxy will be little bit a burden for our Infra to manage the server and deployment.
Also I have a very limited knowledge of HAproxy but as you mentioned that is only solution.
Hence I will give a try to configure it.
