How much RAM for 1000 users?

My case is the second one. One public IP, that’s it.

But then do I allow only 80, 443 through the firewall to the reverse proxy ?

Yes because haproxy cannot manage the UDP traffic. The UDP traffic should be sent directly to JVBs

@emrah

Configured it this way

Now what happens is, the first participant can join any of the host shards successfully. But when the second participant joins, the room crashes.

Refreshing the scenario

  1. My HAProxy Reverse proxy has a Public IP, as is behind a firewall.
  2. 80, 443 is forwarded to the same ports of the HAProxy
  3. 10001-10003 UDP from the same firewall are sent to three different shards where jvb is running on the same port as forwarded - 10001-10003.
  4. I can successfully create meetings from inside the firewall network, but if I join a pre-existing meeting from outside the firewall ( reverse proxy public URL ) , the external participant crashes

@damencho can you help us with this ?

How? What do you see in the client logs?

Are you sticking sessions in the HAProxy based on the URL param room?

@damencho

I tried fetching logs from the js console

Also, the second participant can see that the first one has switched on/ off his cam, mic ( symbols ) but no video or audio can be seen. Also there are some logs when the session crashes, but they get cleared immediately because the page reloads

Are you sticking sessions in the HAProxy based on the URL param room? >> I followed the video that you recommended. HAProxy configuration is the same as mentioned above

Also adding

My HAProxy public URL is - abc.xyz.com
and all the 3 shards have the same URL - pqr.dgf.com

That wont be an issue right ?

This is what you need to get to analyse the problem … but probably it the ICE failed from this log.

Which ip is being advertised by jvb, it should be the public ip where the ip forwarding is done. If that is correct then the forwarding is not working and udp does not reach jvb and ICE fails.

Also, your bridge websocket channel is not being forwarded to the bridge for some reason.

@damencho

  1. This is what you need to get to analyse the problem … but probably it the ICE failed from this log. >> I’ll try to fetch the logs.

  2. Which ip is being advertised by jvb, it should be the public ip where the ip forwarding is done. >> I didn’t get this, correct me if I am wrong, JVB will advertise the private IP only right ?

Reverse proxy ( Public IP ) - Machine 1 ( forwards request to below machine )
JMS 1 ( includes jvb ) - ( Private IP ) - Machine 2
JMS 2 ( includes jvb ) - ( Private IP ) - Machine 3
JMS 3 ( includes jvb ) - ( Private IP ) - Machine 4

Also, your bridge websocket channel is not being forwarded to the bridge for some reason. >> Okaye, I don’t have much idea about websockets. Let me try and fetch logs from the first point.

No, JVB advertises both private and public, and the public is one which clients will use and send their traffic to and where the port forwarding should happen.

You can see in jvb logs something like:

org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Using org.ice4j.ice.harvest.StunMappingCandidateHarvester, face=/10.a.b.c, mask=/x.x.x.x

mask part will be your public IP address. Search in the beginning of the logs for harvester.

You need to configure your reverse proxy to forward the websockets this is described here Self-Hosting Guide - Docker · Jitsi Meet Handbook

As you are running docker I suspect you have the correct settings here for the websockets:

And you are using this nginx rule docker-jitsi-meet/meet.conf at 65563d93710c5c001e7f898b16f29747709509c1 · jitsi/docker-jitsi-meet · GitHub

can you give us some estimation about CPU too?

your comment will be highly insightful for me
@damencho