Solved No sound in Jitsi...
-
I keep trying to experiment with Jitsi package in CloudRon and I have encountered a new problem - there is no sound going through the conference.
Microphone is there, all of the access in the browser is granted, but we can't hear each other.
At the meantime rolled back to the self-hosted Jitsi without the Docker, but I would love to have Jitsi running on Cloudron - any help would be much appreciated.
-
@potemkin_ai so video works, but sound does not? Do you see any related errors in the client or app itself? Also is this with 2 participants or more? This may be relevant, as jitsi transmits video and sound differently if 2 or 3+ participants are in a conference.
With 2 it uses direct connection between the clients, from 3 participants on, all clients send data to the server which relays then. -
@nebulon thanks for the prompt responce!
Nor video nor sounds works, for 2 or 3 participants.Strange enough, it shows that all other conference members are muted - in both 3 participants and 2 participants mode, however they are not muted.
-
@potemkin_ai for a start the 3 participant meeting should go via the app instance on port
10000this is hardcoded in jitsi and can't be changed, so make sure this port is reachable from your client.Further you likely see some connection errors in the browser logs as well as the connection candidates it found for webrtc, so check those.
On top of this, are you using Cloudrflare proxying by any chance for this domain? Just thought of this and it likely will break due to the extra port not forwarded by CF then.
-
Topic has been marked as a question
nebulon
-
Also, are you all on good internet connections?
Jitsi will automatically turn off cameras etc to try to ensure the meeting can go on when people have bad connections.
-
@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?
-
@jdaviescoates thank you, didn't know that, but it's out of question, the internet is stable
-
@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?
-
@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?
-
instructional message such as "DO NOT CHANGE" would stand out more
-
-
Topic has been marked as solved 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.
-
@nebulon cool, thanks!
-
@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:433The 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.
-
@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. -
@potemkin_ai and your fw has open ports for the Cloudron TURN server?
-
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.
-
@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
-
@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
-
@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...
-
@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.
-
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.
-
@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."
-
@potemkin_ai said in No sound in Jitsi...:
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.
-
@robi said in No sound in Jitsi...:
however you did manage to get sound working after fixing the port issue.
Hence the topic is marked solved.Not quite. I had two issues:
-1. Related to the port. Fixed. Indeed.
-2. Blinking issue with Jitsi not-working from time to time.Everything I say here is about second problem.
And yes, I'm aware how ISP works. I used to work for at telecom and other interesting places with a very extensive tech. stack.Hope that makes sense.
-
@nebulon I actually have set up several Cloudron instances and none of them is able to get Jitsi to work. I suppose that if I provide a fresh VM, it wont be able to get it working either. Therefore it might be suitable for debugging.
(I still want to mention at this point that its neither port related, nor a networking issue as I have a working Jitsi (from Yunohost) on one of my VMs)
What do you think?
-
@opensourced Can you tell us on which VPS provider you tried to setup Jitsi? We can then test them out there. Our cloudron/jitsi instances are hosted in DO and they work fine there atleast.
-
@girish We do have our own server farm in a data center. As host for our VMs, we use Proxmox.
-
@opensourced Think we found a few variables that we can set in Jitsi (that the package currently does not set). We will release a new package shortly with the changes.
-
@girish thanks, I'm still looking for ways to move Jitsi running on Cloudron, and would love to unroll my manual installation server.
-
The latest package now has a TCP harvester port defaulting to 4443. At least in my tests changing that or the UDP harvester port 10000 will result in no connectivity. Not sure how to fix this, but hopefully adding TCP improves the situation.
The NAT settings were unclear to me as what to set when using a docker bridge, so those are not part of this package release but hopefully we get down to what they should be set to for the next release then.
-
@nebulon thank you!
I've run out of the patience limit for my clients, so I've got to wait for the next package release. Keep fingers crossed! -
@nebulon said in No sound in Jitsi...:
The NAT settings were unclear to me as what to set when using a docker bridge, so those are not part of this package release but hopefully we get down to what they should be set to for the next release then.
At the bottom of the variables page @girish found, there's a link to a previous page -> docker guide that has NAT info and reverse proxy setup considerations.
-
@girish I'm glad to see your efforts put in this issue. I think we are getting closer! I looked at the sip-communicator config of yunohost - as their jitsi is working on my systems and they actually set those variables.
A further indication that this is the only missing piece is this thread here...
Are there environment variables for the local and the public IPs? I would like to test this.
-
@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?
