Web-socket error on browser console

Hello,

Strange annoying behaviour on browser that come as web-socket errors. I use the latest stable Docker images but the issue persists. The video clarity and screen sharing clarity has been decreased .

The issue starts as soon as 3 member joins. (when JVB in use) . The websocket is already enabled. The firewall is fully open at the moment for testing.

What are the parameters to be validated to ensure the colibri-socket configured properly.? What happens if I disable it.

BridgeChannel.js:83 WebSocket connection to 'wss://mydomina/colibri-ws/:30901/6a7bbee3f2114b0b76f6c?pwd=sometexts failed:

@damencho

Don’t tag people in your posts requesting help unless they’re already assisting you with the issue.

Not sure what you mean by this. But it looks like you have some misconfiguration somewhere. Check your nginx log for errors or share your nginx config.

Alright , Thank you for the repsonce. The Nginx file as follows. This is single shard environment.

user www-data;
worker_processes 4;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 768;
# multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    client_max_body_size 0;

    resolver 127.0.0.11;

    include /etc/nginx/mime.types;
    types {
            # add support for wasm MIME type, that is required by specification and it is not part of default mime.types file
            application/wasm wasm;
    }
    default_type application/octet-stream;

    ##
    # Logging Settings
    ##

    access_log /dev/stdout;
    error_log /dev/stderr;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_types text/plain text/css application/javascript application/json;
    gzip_vary on;
    gzip_min_length 860;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##
    include /config/nginx/site-confs/*;

}

daemon off;

@Freddie

What is the value of this in your config jitsi-meet/config.js at 11eb6689dcb9789d2311f1045e74bee655015d5a · jitsi/jitsi-meet · GitHub

@damencho I have enabled it tried , but the issue persists. This appears to me is the colibri-ws connection to node is failing.

BridgeChannel.js:83 WebSocket connection to ‘wss://mydomain/colibri-ws/xxx.232.xxx.80:30900/631ef766c7e241ff/fe9d5?pwd=3o7ske4on7rq571nvh2a’ failed:

No, I meant /etc/nginx/site-available/your.domain.com-conf

I am using traefik ingress to route the traffic to the web pod in my kubernetes. I think the nginx configuration is not being used in this scenario. Correct me if I am wrong. Anyways my nginx only contains default config file inside site-available.

@Freddie @damencho

Please find my meet.conf

cat /config/nginx/meet.conf

server_name mydomain;

client_max_body_size 0;

root /usr/share/jitsi-meet;

ssi on with javascript for multidomain variables in config.js

ssi on;
ssi_types application/x-javascript application/javascript;

index index.html index.htm;
error_page 404 /static/404.html;

Security headers

add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection “1; mode=block”;

add_header Permissions-Policy “interest-cohort=()”;

location = /config.js {
alias /config/config.js;
}

location = /interface_config.js {
alias /config/interface_config.js;
}

location = /external_api.js {
alias /usr/share/jitsi-meet/libs/external_api.min.js;
}

ensure all static content can always be found first

location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.)$
{
add_header ‘Access-Control-Allow-Origin’ '
’;
alias /usr/share/jitsi-meet/$1/$2;
}

colibri (JVB) websockets

location ~ ^/colibri-ws/([a-zA-Z0-9-.:]+)/(.*) {
proxy_pass http://$1/colibri-ws/$1/$2$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
tcp_nodelay on;
}

BOSH

location = /http-bind {
proxy_pass http://prosody:5280/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host try.clanmeeting.com;
}

xmpp websockets

location = /xmpp-websocket {
proxy_pass http://prosody:5280/xmpp-websocket;
proxy_http_version 1.1;

proxy_set_header Connection "upgrade";
proxy_set_header Upgrade $http_upgrade;

proxy_set_header Host try.clanmeeting.com;
proxy_set_header X-Forwarded-For $remote_addr;
tcp_nodelay on;

}

location ~ ^/([^/?&:’"]+)$ {
try_files $uri @root_path;
}

location @root_path {
rewrite ^/(.*)$ / break;
}

location ~ ^/([^/?&:’"]+)/config.js$
{
set $subdomain “$1.”;
set $subdir “$1/”;

alias /config/config.js;

}

#Anything that didn’t match above, and isn’t a real file, assume it’s a room name and redirect to /
location ~ ^/([^/?&:’"]+)/(.)$ {
set $subdomain “$1.”;
set $subdir “$1/”;
rewrite ^/([^/?&:’"]+)/(.
)$ /$2;
}

BOSH for subdomains

location ~ ^/([^/?&:’"]+)/http-bind {
set $subdomain “$1.”;
set $subdir “$1/”;
set $prefix “$1”;

rewrite ^/(.*)$ /http-bind;

}

websockets for subdomains

location ~ ^/([^/?&:’"]+)/xmpp-websocket {
set $subdomain “$1.”;
set $subdir “$1/”;
set $prefix “$1”;

rewrite ^/(.*)$ /xmpp-websocket;

}

@Freddie

Take a look at this guide:

@Freddie I could see the configurations are correct. I am taking the latest stable docker releases as it is so I dont think so I need to manually make some changes to these files. Any thoughts?

From my experience, websocket errors can usually be tracked down to one (or more) of three things:

  • Bad nginx config
  • jvb.conf misconfiguration
  • Firewall/port access issues

I’d suggest going through each of those possibilities carefully to pinpoint your specific issue.

1 Like

I have made all ports open for testing and the issue remains same.

I am validating nginx and jvb meanwhile.

Is the error in the picture familiar to you? Will it help to pinpoint the issue?

@Freddie