No sound in Jitsi...

[potemkin_ai]

@nebulon my installation was with a port different from 10000 - reinstalling now, thank you!

A question then - what's the point of asking the port input at the installation process, if the port shouldn't be touched?

[potemkin_ai]

@jdaviescoates thank you, didn't know that, but it's out of question, the internet is stable

[nebulon]

@potemkin_ai the only reason we show it is, that our dashboard has no exception for such a case, which is why the description says "only default works" hopefully upstream supports other ports at some point though.

Is this solved then with the default port?

[potemkin_ai]

@nebulon need recheck and will let you know.

Probably worth to rephrase a sentence for the guys like me?

Something like: "Don't touch the port, unless you know what you are doing! Here is why" with a link on this forum?

[robi]

instructional message such as "DO NOT CHANGE" would stand out more

[potemkin_ai]

@robi yes, I was thinking about something of the kind, just though it might be too aggressive

@nebulon , the problem was with port, indeed, thank you!

[nebulon]

Given that we found that traccar also has essentially fixed ports, we decided to add a proper read-only flag to the manifest for ports, which will then be part of the next release now.

[potemkin_ai]

@nebulon cool, thanks!

[potemkin_ai]

@nebulon , unfortunately, it doesn't work again...
The video and audio doesn't work even for 2 participants for me and users report that it stops transmitting the sound after 3rd user attached.

Can't upload full log file due to forum restriction, but here is what seems to be a key lines:

BridgeChannel.js:84 WebSocket connection to 'wss://server.domain/colibri-ws/default-id/9e492323b5fe10c7/2dd3002a?pwd=2dhurejj37lfravd497k7t2jo7' failed: 
_initWebSocket @ BridgeChannel.js:84
t @ BridgeChannel.js:103
Logger.js:154 2022-08-15T07:24:24.118Z [modules/RTC/BridgeChannel.js] <e.onclose>:  Channel closed by server
Logger.js:154 2022-08-15T07:24:24.118Z [modules/RTC/BridgeChannel.js] <e.onclose>:  Channel closed: 1006 
r @ Logger.js:154
e.onclose @ BridgeChannel.js:433

The port is 10'000, nothing has been changed there.

Any help would be much appreciated!

[robi]

@potemkin_ai

Check Cloudron services to make sure your TURN server is working.

Otherwise, I would uninstall and reinstall to make sure the port is unchanged everywhere.

Is any other upstream firewalling or routing happening or do you have a public IP for it?

It's been pretty bulletproof here otherwise.

[potemkin_ai]

@robi thank you.
TURN server is working and it's very fresh install of Jitsi.
Cloudron is behind a firewall/VPN, but once you are in, there are no restrictions and another (old, undockered) Jitsi works just fine here.

[robi]

@potemkin_ai and your fw has open ports for the Cloudron TURN server?

[nebulon]

I think you have to report this upstream as we are no jitsi experts here and given that the other instances of the package on Cloudron work fine, this may be some specific error with your routing setup. Generally only on the 3rd partivipant the video (and audio) bridge will be used but that is pretty much just a simple relay.

[potemkin_ai]

@nebulon I don't think that would be accepted, as I have the very same Jitsi running non-containerised and it works just fine.

I reinstalled the Jitsi again and it seems like working fine for now - will keep on testing

[opensourced]

@potemkin_ai have you made progess so far?

I have been running into the similar (if not even the same) issue here. My VM is behind a firewall in a LAN. Ports are open and everything is ready to go, but sound and image doesn't work.

The interesting thing is, that running Jitsi on Yunohost, works like a charm. Compared to your situation with your other working instance of Jitsi, i would assume a configuration issue. I have started analyzing the config files, however not found a solution so far.

If i find a solution, i will post it here...

Cheers

[potemkin_ai]

@opensourced I end up giving up on Jitsi on CloudRon unfortunately.
I'm not sure if it's something specific to Docker-izing it (as I had the same problems earlier, when it was Docker-ized under CapRover) or not.

The problem is that it doesn't work sporadically and troubleshooting it close to impossible, especially, since the problems are not easy to reproduce.

I returned to a dedicated host with Jitsi that I setup and upgrade (read: re-install) with this wonderful script - it worked without issues for me for half of the year, hope it would keep doing so going further.

@nebulon , JFYI.

[opensourced]

@potemkin_ai Well thats pretty frustrating... jitsi would be a key feature for my clients to decide for cloudron. Anyway, I guess i will invest another afternoon before i will drop my work on this front.

@nebulon If you are interested in debugging this issue, I would be happy to provide a vm with ssh access to get this issue solved. Where can i actually find the cloudron-jitsi repo? Didnt find it on your Github...

[nebulon]

@opensourced the repo for the Cloudron package is at https://git.cloudron.io/cloudron/jitsi-app

Thanks for the offer, but it is not quite clear how a VM will help us to reproduce this. At least I wasn't able to reproduce this on a few Cloudrons I've tried and eventually gave up.

[robi]

@opensourced

I agree with @nebulon here, as we have a client running the MS hypervisor with a VM for Cloudron on a NATed and dynamic IP with no issues.

If you plumb everything correctly, Jitsi just works.

[potemkin_ai]

@robi any ideas what can I plumb incorrectly, if I just installed Jitsi on CloudRon and sometimes it works and sometimes - not?

At the very same time, Jitsi installed from the script I mentioned earlier, on the server at the very same environment, without Docker, works bulletproof?