I’ve installed Jitsi meet on ununtu 16 cores and 32 RAM, but it couldn’t handle a room with 100 person, I’ve followed all the configuration in Self-hosting article.
I’m asking abou the best way to implement jitsi meet for production env.
how many servers?
how many JVB?
multi shards or multi video bridges?
Is there TURN server by default or I have to make one?
Thank you so much
What do you mean by “couldn’t handle”? What is the issue?
many users have no A/V, reported that they can’t hear others
Don’t you have this problem when there are ~20 participants?
Your server resources seem OK. This may be a bandwidth issue.
yes it’s not happening when for ex 10 users, and I need to get the most out of jitsi in a production env. to serve all people joined a room.
So, I realy need answers for my questions above.
Thank you for your replies.
What’s your network speed (upload and download)? What errors do you see in the browser logs of the clients that lost audio and video? What about jicofo and jvb logs?
my server at Azure VPS with very high speed, and I coudn’t actully see client’s browser log
Share your JVB and Jicofo logs
logs are too large, how can I send it to you?
Upload to a free public online storage and link to it.
Can you share your jicofo.conf?
And yes, there are reasons to suggest you have bandwidth issues, notwithstanding your assessment of your network speed.
time wget https://your-server.com/app.bundle.min.js.map
against … your server … gives me about 300 Kb/s vs 2Mb/s for meet.jir.si, 4 for alpha.jitsi.net, and 1Mb/s for framatalk.org. In short, for simple file serving, your server don’t seem to deliver a top performance.
16 cores with a ‘very high bandwidth’ seems to give astonishingly slow results, can you provide a link to the actual configuration in Azure catalog ?
t# Jicofo HOCON configuration. See reference.conf in /usr/share/jicofo/jicofo.jar for
#available options, syntax, and default values.
trusted-domains: [ "recorder.meet.example.com" ]
You didn’t disable BWE in your sip-communicator.properties, right?
Ok, you likely didn’t disable it, if you don’t know. BWE = Bandwidth Estimation
Everything right now points to your network. There are a lot of bandwidth alarms in your log. And the fact that you’re able to successfully host smaller meetings aligns with that finding. Bandwidth is the most important resource for WebRTC, so if you’re having challenges with the number of participants you’re able to host, it’s the first suspect.
Try using iperf (or any other tool) to test your actual network speed on your server.
thank you so much for your help, Now I need to know a few things about jitsi
Regarding to TRUN
is ther turn server installed by default?
if so, is there a need to make it listen to 443?
is it used in meetings more than two persons?
And please let me know which alert in the log that refers to the bandwidth?
coturn is a recommended package of
jitsi-meet, so it’s installed by default if you don’t explicitly set
If it’s on the JMS server and if participants cannot connect it through
5349, it’s needed an extra
nginx configuration to allow TURN traffic through
yes, it’s used when a participant cannot connect the other peer or JVB directly.
What bandwidth speed do you recommend for such sitiuations/capacity?