Websocket connection failed, channel closed 1006

We have jitsi-meet running (align with jitsi-meet_5765) with other components in a single server. we mainly were tweaking on front end part but suddenly in a conference we started facing this issue. As per my knowledge no change was made in server. then we tried to create conference after scheduling again then found this thougfh it was working perfectly:

BridgeChannel.js:83 WebSocket connection to ‘wss://mydomain.com/colibri-ws/jvb1/3f99411f13299bd9/ca324fff?pwd=2uf77uqbjnbi7nn5f734l8cq8g’ failed:
and
[modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>: Channel closed: 1006

and no audio/video is passing through users and if one disconnects every other gets disconnected. I tried some solution (like nginx colibri location block) but didn’t work.
why is this happening out of no where?

my jvb.conf
videobridge {
        http-servers {
                #public {
                 #   port = 9090
                #}

                public {
                        port = 9090
                        key-store-path=/etc/jitsi/videobridge/keystore.jks
                        key-store-password=mypass
                }

        }

   websockets {
      enabled = true
      domain = "testcon.kloudtalk.com:443"
      tls = true
        # or false, depending on your HTTP server config
        # The port here is the 'advertise port' for websockets, which means the publicly-accessible
        # port clients will use.  This may match the public http server port, but could also be different
        # if a proxy is being used.
        # A server ID can optionally be provided.  This is useful when a set of jitsi-videobridge instances
        # are fronted by an HTTP proxy and they advertise the same domain.
      server-id = jvb1
    }

}
my nginx collibri block
# colibri (JVB) websockets for jvb1
    location ~ ^/colibri-ws/default-id/(.*) {
        proxy_pass http://127.0.0.1:9090/colibri-ws/default-id/$1$is_args$args;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        tcp_nodelay on;
    }

thanx in advance :heartbeat:

1 Like

stopping to work out of the blue has been the default behaviour for auto-updating software for quite some time now, and most Jitsi-meet clients are auto-updating. So you could do worse than checking on your browser version(s) and if your users are with Chrome, try a downgrade or test with the Electron client, it’s lagging a bit behind latest Chrome version. Did you follow the forum about recent Chrome changes forcing Jitsi-meet upgrades ?

Thanx for the reply.
not much… what can I do now ? my other partners are also facing same error… so should I check server side component version’s and then downgrade them to be aligned with jitsi-meet_5765 ?

as I said, first check with downgraded Chrome or the Electron client, if it works it’s an immediate problem solved and an explanation for solving it long term.

I did run in our electron app which has early version of chrome …the I found these errors (along with prervious errors) :

BridgeChannel.js:83 WebSocket connection to ‘wss://testcon.kloudtalk.com/colibri-ws/jvb1/f49c28f158d751f0/a878890e?pwd=16p9e5h43mtell426eu66ka8lj’ failed: Error during WebSocket handshake: Unexpected response code: 200

<Object.getGlobalOnErrorHandler>: UnhandledError: The play() request was interrupted by a new load request. DOMException: The play() request was interrupted  |  Web Script: null Line: null Column: null StackTrace

Uncaught (in promise) DOMException: The play() request was interrupted by a new load request. DOMException: The play() request was interrupted  |  Web

hmm… you did talk about a custom front end yes ? In this case I’d try to downgrade your Javascript code.

mm actually we did not cutomize so much… mainly in auth part and some visibility like components and stuff… this shouldn’t collapse with websocket? I did some searching about the error and found out that the 1006 code means websocket (between frontend and video bridge i guess) crashed during handshake or the protocol is not allowed like stuff… but i just dont know how can this be possible within few moments, I even then cheked websocket config partt from handbook and even posted in earlier post… anyway, how can I downgrade my js or should I downgrade my videobridge version? can this problem be happened if I use custom front end (which was mainly aligned with 5765) and then update/upgrade video bridge component?
Thanx in advance :heartbeat:

Does it continue after restarting prosody, jicofo and JVBs?

yeah… I tried restarting every component … even restarted the server… but same problem persist… is there anyway I can pinpoint the specific problem? like may be jvb version mismatch or somehow jvb config got broken?
some addition to it… we sometimes faced problem in audio/video problem like one user opened his audio/video but some other isn’t getting it… or even facing problem opening his microphone/camera… can this be happened because of bridge channel error though getUserMedia() is client side thing?
Thanx in advance :heartbeat:

Hi,
Are you sure the colibri websocket configuration you share in your first post is the one you’re using in your server ?
You have : ^/colibri-ws/default-id/(.*) In your nginx and server-id = jvb1 in your jvb config
So your client tries to open a websocket on : wss://mydomain.com/colibri-ws/jvb1/ which doesn’t exist in your nginx config.
Regards,
Damien.

thanx for the reply.
should I just comment out server-id? actually it is must needed for additional jvb other than same machine i guess… I dont fully remember it was the same configuration before but when it ran into error may be I tried this too

Hi you must have a coherent configuration between nginx websocket proxy and jvb server-id.
For multiple bridge config with for exemple 2 jvb : server-id=jvb1 and server-id=jvb2
You must have a specific location for each bridges in your nginx config :
^/colibri-ws/jvb1/(.). And ^/colibri-ws/jvb2/(.)
Regards,
Damien

let me give a try and report, thanx

I first tried commenting out “server-id” field in jvb.conf thyen restarting jvb, nginx, jicofo, prosody and then again tried with uncommenting server-id from jvb.conf and hard code “jvb1” in nginx instead of “default-id” followed by restarting all other components. but unfortunately problem persists :

WebSocket connection to ‘wss://mydomain.com/colibri-ws/jvb1/e3e6655792f078e6/747f9247?pwd=4bsrqqdo2r9j3l1sd08p1jrd5q’ failed:
_initWebSocket @ BridgeChannel.js:83
t @ BridgeChannel.js:102
Logger.js:154 2021-08-17T10:32:53.775Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>: Channel closed by server
Logger.js:154 2021-08-17T10:32:53.775Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onclose>: Channel closed: 1006

If JMS (nginx, prosody, jicofo) and JVB are on the same server, remove server-id line from the JVB config and use the default colibri block in Nginx config

is there any other way I can try to fix or findout which part is causing problem?
Thanx in advance :heartbeat:

well, running full debug trace on web console/jvb/jicofo/prosody/web server and comparing them to full debug traces of a running vanilla server with the same basic version could be a way. Since you did unspecified changes to the Javascript - I disagrree on your point that any change to ‘auth’ - whatever it is - can be innocuous - and seem to run mismatched versions of software between client and server, it’s very difficult to do more than idle speculation. IMO you are doing risky stuff.

yeah I mean actually the changes in front end were made by the developpers before me though I have a good idea where those changes are… from that point of view I am just little more confused how can this affect websocket connection between client and video bridge though it was working just perfectly fine… and suddenly channel starts closing…
I cheked that when frst 2 user connects it gets the advertised websocket url (transport layer), even in network tab no error shown for this, rather shown finished (so handshake happened). but console is showing alltime that channel closed : 1006 (might be server unexpectedly closing connection). I just downgraded the other components but same :slight_smile:

I have just now the idea that it’s easy to test if this customized client has something fishy, just use 2 computers, download on each jitsi-meet and lib-jitsi-meet source versions corresponding to the server components, make the software and run it against the server to run a room between the 2 clean original Jitsi-meet. If it has the same problem, maybe you have a network problem.

1 Like

I just wanted that to be fixed. I then uninstall fully - everything and cleared… then reinstalled with latest (no custom frontend). now p2p is working fine sending video/audio but with 3 person (using jvb) same problem… cant caonnect to websocket, no opened channel
Thanx in advance for any help :slight_smile: