@robi cool, thanks figured that might be the case, thanks for confirming! (I probably should've just tried it!)

@frei said in Share your experience with Jitsi:

The client's intention is to host educational conference calls with tens or hundreds of callers. Is this a reasonable expectation?

I'd guess not

For something like that you're likely going to want a bare metal install, and possibly BigBlueButton which was built for exactly that instead of Jitsi

@girish , I understand this topic is marked as solved and might fall out of sight - so I'm wondering if there are any updates on that?

Edit: it's definitely jitsi in Matrix, this is what we were presented with for our 3 way (successful) video call, with screen sharing:

8d4b28c5-9035-4be2-8b68-cec1de5558c7-image.png

Was just stock cloudron matrix, using the stock cloudron element web client on the customer side of the call.

95477f5b-1ba7-4641-9d9e-2b72cf274b59-image.png

We could not do a successful 3-way video call with this same customer, on the same browser, using the stock standalone cloudron jitsi instance.

We're on cloudron 7.2.5

@nebulon I noticed that the deprecated notice was added in Mar, 2021.

Unfortunately there is no official development roadmap so it might just take much longer.

@benborges allowing to change the port is just a limitation of the platform, where marking specific ports as locked is not yet supported.

@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
ed9414c3-74b3-46dd-94f7-41561e9c0809-image.png

Installing with "Allow all user from this Cloudron"
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.

@jdaviescoates I am also interested in recording Jitsi conferences.

If you use the jitsi.org service on the main website for conferencing, there is a tool in the menu allowing people to record. Unfortunately (and rather strangely!) it prompts you to login to DropBox (proprietary software) in order to do so, without any option for a custom alternative...

@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.

Currently only the frontend bits can be configured with the app package. Essentially everything from https://github.com/jitsi/jitsi-meet/blob/master/config.js which can be put in /app/data/jitsi-meet-config.js.

User authentication (which JWT tokens will do in this case) is currently not possible to customize and the current package does not yet support JWT tokens.

Regarding the config files, The ones used are symlinked into /etc and can be found in /run. Those however are recreated on every app restart so currently no permanent customizations can be made to those.

@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.