video quality impaired: the bridge channel has been disconnected #1637
Comments
|
Any sense of direction of where to look would be helpful |
|
Have you done port forwarding of port 30300? So when a client sends a udp packet to the public address of the bridge it will be routed to the bridge instance? |
|
All that we have setup is https://github.com/hashbang/gitops/blob/master/jitsi/040-ingress.yaml |
|
I think you are missing the ports so clients can reach jvb. Also 9090 is not required to be public. You should close that. |
|
UDP for which path? |
|
From the client to the bridge. |
|
So all UDP traffic should be sent to the bridge? |
|
We have something like this |
|
port 9090 is to be accessed only from nginx, you do not need it public. You need this port accessible from the public internet: https://github.com/hashbang/gitops/blob/28cf6f504709011f593e9b345c49ff6f62a8ddeb/jitsi/010-jvb-service.yaml#L13 |
|
Yes but at which path will the client send requests that should end be sent to that port? |
|
As you can see that is how it's setup with kubernetes |
I don't understand what is that, maybe cause I have no idea about k8s. It is just that you need to make sure the UDP packets sent from clients are reaching the jvb process. |
What I am asking is which endpoint does the client send UDP packets to? It seems like the only place is /colibri-ws |
|
Does any of these logs seem relevant? |
|
The UDP traffic is entirely orthogonal to the /colibri-ws endpoint on the JVB. The UDP port is advertised by the JVB to the end client and the client sends UDP packets to the JVB through this port. Separately, the client also needs to make a websocket connection to the colibri-ws endpoint on the JVB. It discovers this URL from the JVB, so as long as whatever is proxying your traffic can forward to the JVB in the end, you can configure the JVB to advertise whatever colibri-ws URL you desire. Traditionally a proxy layer is used (nginx is common but not required) to route all /colibri-ws requests to a central nginx and then proxy to the appropriate bridge based info in the URL (such as the IP you see in the above). Hope this answers your question. |
|
I already reported this error in #1599 But no success till today |
|
In my setup I used nginx-rproxy in front of docker-jitsi-meet. I had the same issue like described in the title with every account using my jitsi instance, after updating from stable-8960-1 to stable-9111. The Console at the developer tools showed issues with colibri-ws. So I switched from using websockets to SCTP. This solved the issue, but few accounts were disconnected every few seconds. So I reactivated using websockets and disabled using sctp again and configured a websocket like described here but instead of addressing |
|
@Fopsala - what is the outcome of your Desktop testing? |
|
it works :) |
In NPM are you redirecting 8000 or 8443 to the public ip? are you enable websockes and block common exploits? location /xmpp-websocket { |
|
port 9090 at jitsi-meet-jvb service is just for colibri-ws. xmpp-ws needs a different handling. for me it worked to forward xmpp-ws to jitsi-meet-web service like described in the default setting. |
Would you mind if I send a dm to you? |
|
I tried to change this proxy pass, I deleted everything and tried again but didnt work. I don't have any clue why its not working, also the docker networks are connected I added in the compose the nginx proxy manager network in each container. |
|
This is all best addressed via questions in the jitsi community: https://community.jitsi.org There is also some details about the various parameters to test with: In general if this isn't proxying properly, it's likely you have a mismatch between the colibri ws regexp and the JVB identifier in the bridge or the connection between the proxy and the JVB. |
I have an instance of Jitsi Meet running at https://meet.hashbang.sh the current configuration is located at https://github.com/hashbang/gitops/tree/master/jitsi.
There are a few errors that I could use some clarification around:
During a call, we are getting a constant occurrence of the alert stating
These seem to be the relevant logs in the JVB
In the browser I am noticing some strange errors:
The text was updated successfully, but these errors were encountered: