Websocket error jitsi on Docker

Hi,
I have installed the Docker version of jitsi meet from the package docker-jitsi-meet-stable-6826.zip on my server running Ubuntu 18.04.
When I try to connect, I get disconnected immediately and my Chrome browser shows a websocket error:
{“autoGainControl”:true,“echoCancellation”:true,“noiseSuppression”:true}}
strophe.umd.js:5463 WebSocket connection to ‘wss://myIP.net/xmpp-websocket?room=closedgovernorsloseaside’ failed: Error during WebSocket handshake: Unexpected response code: 404
_connect @ strophe.umd.js:5463
connect @ strophe.umd.js:2368
… where myIP.net is the IP address of my server.

My .env file is: (passwords obfuscated) and myIP.net is my external server IP address (fake, not my actual IP)

shellcheck disable=SC2034

Security

Set these to strong passwords to avoid intruders from impersonating a service account

The service(s) won’t start unless these are specified

Running ./gen-passwords.sh will update .env with strong passwords

You may skip the Jigasi and Jibri passwords if you are not using those

DO NOT reuse passwords

XMPP password for Jicofo client connections

JICOFO_AUTH_PASSWORD=fxxx

XMPP password for JVB client connections

JVB_AUTH_PASSWORD=a59xasere

XMPP password for Jigasi MUC client connections

JIGASI_XMPP_PASSWORD=baaaserasarze3

XMPP recorder password for Jibri client connections

JIBRI_RECORDER_PASSWORD=9favesrea7

XMPP password for Jibri client connections

JIBRI_XMPP_PASSWORD=8slktse5

disable websockets → uncomment

#ENABLE_SCTP=1

#ENABLE_COLIBRI_WEBSOCKET=0

#ENABLE_XMPP_WEBSOCKET=0

end disable websockets

Basic configuration options

Directory where all configuration will be stored

#CONFIG=~/.jitsi-meet-cfg

CONFIG=/opt/jitsi_docker/.jitsi-meet-cfg

Exposed HTTP port

HTTP_PORT=800

Exposed HTTPS port

HTTPS_PORT=4430

System time zone

TZ=America/Denver

Public URL for the web service (required)

PUBLIC_URL=https://myIP.net

IP address of the Docker host

See the “Running behind NAT or on a LAN environment” section in the Handbook:

Self-Hosting Guide - Docker · Jitsi Meet Handbook

DOCKER_HOST_ADDRESS=myIP.net

Control whether the lobby feature should be enabled or not

#ENABLE_LOBBY=1

Control whether the A/V moderation should be enabled or not

#ENABLE_AV_MODERATION=1

Show a prejoin page before entering a conference

#ENABLE_PREJOIN_PAGE=0

Enable the welcome page

#ENABLE_WELCOME_PAGE=1

Enable the close page

#ENABLE_CLOSE_PAGE=0

Disable measuring of audio levels

#DISABLE_AUDIO_LEVELS=0

Enable noisy mic detection

#ENABLE_NOISY_MIC_DETECTION=1

Enable breakout rooms

#ENABLE_BREAKOUT_ROOMS=1

Let’s Encrypt configuration

Enable Let’s Encrypt certificate generation

#ENABLE_LETSENCRYPT=1

Domain for which to generate the certificate

#LETSENCRYPT_DOMAIN=meet.example.com

E-Mail for receiving important account notifications (mandatory)

#LETSENCRYPT_EMAIL=alice@atlanta.net

Use the staging server (for avoiding rate limits while testing)

#LETSENCRYPT_USE_STAGING=1

Etherpad integration (for document sharing)

Set etherpad-lite URL in docker local network (uncomment to enable)

#ETHERPAD_URL_BASE=http://etherpad.myIP.net:9001

Set etherpad-lite public URL, including /p/ pad path fragment (uncomment to enable)

ETHERPAD_PUBLIC_URL=https://etherpad.myIP.net/p/

Name your etherpad instance!

ETHERPAD_TITLE=Video Chat

The default text of a pad

ETHERPAD_DEFAULT_PAD_TEXT=“Welcome to Web Chat!\n\n”

Name of the skin for etherpad

ETHERPAD_SKIN_NAME=colibris

Skin variants for etherpad

ETHERPAD_SKIN_VARIANTS=“super-light-toolbar super-light-editor light-background full-width-editor”

Basic Jigasi configuration options (needed for SIP gateway support)

###########################################
I’ve seen many instances of a similar issue but
I have not been able to figure this out and have googled extensively. Any help would be greatly appreciated.
Thanks in advance!
Phil

You need a valid TLS certificate for things to work properly, which you can’t use with an IP, you need a valid domain name.

Hi saghul,
Thanks for your prompt response!
I do have certs which are apparently working. This is a Docker container install and was installed as recommended in the Jitsi docs. It appears that my browser is showing a good cert when I address Jitsi in the Chrome and FireFox browser. I was able to get jitsi somewhat working by disabling websockets with the three commands in the .env file:

disable websockets → uncomment

ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0

end disable websockets

I’m still having problems connecting audio and video to Jitsi from outside my LAN but it appears to work inside my LAN.
Thanks again,
Phil

I think I’ve solved the video and audio connection problem. Still have the websockets problem with the ENABLE_XMPP_WEBSOCKET=1 setting. Thanks

Can you check the network tab in the browser console and see if the URL where the WS connection is attempted is correct?

Hi Saghul,I’m an amateur and not sure what you meant, this is my interpretation of the WS connection in the Network tab of the browser inspect menu.
My Jitsi site is at microcraftx.ddns.net:4430 i.e. the port is set to 4430 via the .env configuration to avoid conflict with my webpages at port 443. Jitsi is running in the Docker box. I believe that my host is microcraftx.ddns.net. Of course, I’m getting WS 404 errors still as below from the console.
I am using dynamic dns to resolve microcraftx.ddns.net to a public IP and this test is being run on microcraftx.ddns.net server.
Thanks again for your help,
Phil

What did you set as PUBLIC_URL? I think we don’t support running on non-standard ports very well TBH.

Hi Saghul,
Thanks. From my .env file:
PUBLIC_URL=https://microcraftx.ddns.net

If I have websockets enabled (I think the default) and set the ports in my .env file to:

Exposed HTTP port

HTTP_PORT=800

Exposed HTTPS port

HTTPS_PORT=4430

I get the websocket errors I mentioned previously.
If I turn off Apache2 (running on ports 443 and 80) and set the ports in my .env file to with websockets enabled (I think this is the default):

Exposed HTTP port

HTTP_PORT=80

Exposed HTTPS port

HTTPS_PORT=443

I get no websocket error and I can start a meeting.
If I use nonstandard ports e.g. 800 and 4430, AND disable websockets:
from .env file:

disable websockets → uncomment

ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0

end disable websockets

Then I get websocket 404 errors as described in our past emails.
Note that I considered websockets enabled when the above were commented out as (websockets enabled):

disable websockets → uncomment

#ENABLE_SCTP=1
#ENABLE_COLIBRI_WEBSOCKET=0
#ENABLE_XMPP_WEBSOCKET=0

end disable websockets

Thanks so much for helping me resolve this!
However, if I may ask, is there any advantage to enabling websockets? Please pardon my ignorance!
Any ideas how I could run ports 4430 and 800 with websockets or would it be best to just stick with standard ports and modify my Apache services - or stop Apache while while running Jitsi meetings?
Thanks again!
Phil

Hi Saghul,
I had a friend in the Linux Users’ Group explain websockets to me. Apparently, websockets allows for direct connection of audio and video streaming.
Running the websockets with the standard ports, it appears that Jitsi ran great with five user. Some stuttering and video dropouts but most likely due to network bandwidth limitations.
I am VERY happy to have installed Jitsi! Great work on the part of Jitsi developers!
Thanks,
Phil

1 Like

Hi Saghul,
If I may, since I can get Jitsi-meet to work on a nonstandard port if I disable websockets, is there any compelling reason to use websockets? It appeared to work without websockets but I’m wondering if there would be a significant performance hit without websockets? I have plenty of CPU power and RAM here so I’m not concerned so much about CPU server loading, but CPU loading of others in the meeting and also bandwidth efficiency could potentially lead to significant drops in Jitsi performance without websockets? I can benchmark this at some point but wondering if you had an obvious answer?
Thanks,
Phil

WebSockets are more performant than the alternative (BOSH). This is specially relevant for large meetings.

Thanks for the information!
Phil