@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!
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.
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 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...
@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.
@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...
@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?
Docker isn't the issue, especially since it works for most of us here. No sense in blaming Jitsi either.
So look at networking gear settings and how they handle all the connections that Jitsi requires.
If it's intermittent, it could be a timing issue or port setup issue upstream from Cloudron. No sense in blaming Cloudron.
Map out each hop and troubleshoot without skipping steps or making bad assumptions.
Understanding the issue is key.
@robi apologies, not sure when I blamed anyone and I don't really understand how to apply your words to my real-life experience here... It doesn't work (stable) when running on Cloudron; it does work when installed with a script with Docker. As easy as that.
Understanding the issue is key.
Agree. And here are the facts:
It didn't work (stable) when installed on CapRover as a one-click-application. It did work like a rock when installed from the script.
Could it be a mixture of virtualization (my provider uses KVM) and Docker and Linux - maybe.
None of us seems to know that. But I see what I see - Jitsi running on Ubuntu Linux 18.04 and Ubuntu Linux 20.04 on top of KVM inside Docker is not stable.
One thing I can in common here - it's KVM, Docker & Jitsi.
It doesn't seem like anyone involved has resources and or knowledge to troubleshoot this, so I see quite reasonable to repeat myself: "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."
apologies, not sure when I blamed anyone
It's not about blaming people or that you did so, it's about finding fault with systems that work for nearly everyone else.
You're posting here, in a Cloudron forum, where Jitsi, docker and the entire stack just works.
You had a "reading" / port issue, so this topic is solved. Right?
Perhaps it's time you look at a different VPS provider, or ask in another topic which ones have no issues with having Jitsi installed.
@robi my issue is not solved; changing an ISP just to offer users to work as a guinea pig is nor easy for any complex setup, nor client-friendly.
In a way I understood, there is nothing to be done on the topic, so my best offer is to settle this as a know-issue, luckily happening not with everyone or not happening under Microsoft Hypervisor and that is has no know root cause and hence no resolution.
@potemkin_ai I hear you, and the frustration behind this, however you did manage to get sound working after fixing the port issue.
Hence the topic is marked solved.
The other issues you are having are not related to Cloudron or it's supported use. That part is up to you, right?
ISPs are highly complex stacks with many moving parts.
From the networking equipment, firewall rules and other protection and network address translation technologies, each is different.
Then comes the virtualization stack and configuration, and another layer of networking specific to that inner stack.
Then you get into the OS install and Cloudron managing itself.
I hope you can appreciate that this forum helped you solve a self caused user error.
I don't agree with your conclusions, hence I am replying here to help you see where to look, however my time is limited and free consulting has its limits.
Inconvenience or not, your unmentioned choice of ISP and many nested stack isn't working for you as you expect. Hence the suggestion to try another ISP, many of which offer free trials even.