@robi good catch. Looks like the upstream package generates "backup" cert files on every install. Not sure why, they are all just self signed certs. I made our startup script delete them.

I have pushed a new package to fix this. Thanks for reporting @robi

@ApplegateR it's a problem in the app packaging, existing jitsi instances upgrade to a new port, but the port is not checked/enabled in the app config. ;-/ Yes fixed by checking that box, however everyone's jitsi instances are down until then.

@plusone-nick said in Jitsi Problem - Are you the host? Authenticate: Testing Results; Installing with "Leave user mgmt to app" the app installs with no user auth and it has a generated user/mod already logged in [image: 1661725279721-ed9414c3-74b3-46dd-94f7-41561e9c0809-image.png] Installing with "Allow all user from this Cloudron" [image: 1661725331494-3025504d-b704-4a33-a842-acb32b33a3ae-image.png] and I use my Cloudron username (not the email) with my standard Cloudron password and it works If you are using User/Group Policies double check them as I had a similar use case with a standard user not being able to join as they did not have the right permissions Hope this helps! It certainly does! Thank you very much for investigating. I reinstalled and it worked right away as you mentioned, when the option to leave it to the App was selected. I think we will need to develop some terminology such that the difference between Cloudron (the account here) and the Cloudron instance we are running is clearly signaled.

@nebulon I've always thought it was coming from the sounding of running apps in the cloud. And so that is why one needs its apps to be cloud run(ed), or even cloud r on whatever that sounds loudly pronounced in some part of the world.

@nebulon the oposite is the case. for now i only allowed udp on port 10000.

@girish i have tested with some cloud jitsi, i actually managed to drop the cpu consumption a lot by disable the video background in interface_config, it was significant better after disabled, could you assist to add this configuration in cloudron for us as well? thanks in advance. This is the forum that i referred https://community.jitsi.org/t/high-cpu-utilization-on-client-end/25764/24

Yes, we've been enjoying it as well. It's our primary way to connect now. No more NC:Talk, BBB, etc.

@nj the app package is still unstable, can you try to reinstall? Also the current package version is 0.6.0 by now.

@jdaviescoates just for information. Jitsi will do a direct p2p connection with two meeting participants. Once a 3rd person joins, it will use an SFU. So the connectivity specifics are quite different between 2 and more meeting participants.

@ericdrgn said in Jitsi self-hosting behind NAT hair-pinning: @ei8fdb did you get it working? I have had that port open since installation (I also self host) but mine has no audio or video either. Similar problem I have to audio calls through matrix... It all works fine on the same network but not if devices are on different networks and as far as I can tell the logs show everything working fine. Hi @ericdrgn I was waiting to have the time to test this morning. I have tested just now: server (8GB memory & 30% CPU dedicated) on home internet IP clientA (laptop, browser) on external WiFi network clientB (mobile android device, jitsi client) on mobile network I did have video, and audio from both clients. If you try some calls and grep for the messages I got? You can see them in the paste link. Lemme know if you want any more information/help.

@plusone-nick said in Jitsi integration with rocket.chat: @MooCloud_Matt @luckow my #1 question: do we know if Cloudron authentication will be implemented? I'd imagine some level of access must be public for none authorized users to join but what about spam/malicious users making rooms? nevermind just saw: https://forum.cloudron.io/topic/6473/jitsi

Ah that is actually not a jitsi issue, but a platform bug. I have seen that sometimes during e2e tests, but so far I wasn't able to reproduce this reliably. As you mentioned a retry usually works then. Something with docker recycling container IPs.