Attention: If you enable websockets in your deployment

If you have not done work to explicitly configure websockets in your JVB, this shouldn’t affect you.

If you run your own JVB and use websockets, after upgrading to JVB version 2.1-314 or higher you’ll need to add this to /etc/jitsi/videobridge/jvb.conf if it is not present:

videobridge {
    ...
    websockets {
        enabled = true
        ...
    }
}

If you do not have a /etc/jitsi/videobridge/jvb.conf, you can add this to /etc/jitsi/videobridge/sip-communicator.properties

org.jitsi.videobridge.rest.COLIBRI_WS_DISABLE=false

You do not need to change any other values of your websocket existing websocket config.

The websockets doc in the bridge has been updated to reflect this.

Background:

Before JVB version 2.1-314, websockets were enabled by default, but the public HTTP server (required for the websocket service to run) wasn’t, so they weren’t turned on. This was necessary as websockets required additional configuration to work correctly, so having them on by default would be broken anyway. In this commit, this behavior was changed: the public HTTP server and the websocket configuration were split from one another and websockets are now disabled by default and must be explicitly enabled.

3 Likes

We are using websocket currently JVB 2.1-273 with this configuration

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc

org.jitsi.videobridge.xmpp.user.shard1.HOSTNAME=10.15.0.199
org.jitsi.videobridge.xmpp.user.shard1.DOMAIN=auth.vroom.domain.com
org.jitsi.videobridge.xmpp.user.shard1.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard1.PASSWORD=testpass
org.jitsi.videobridge.xmpp.user.shard1.MUC_JIDS=JvbBrewery@internal.auth.vroom.domain.com
org.jitsi.videobridge.xmpp.user.shard1.MUC_NICKNAME=jvb1
org.jitsi.videobridge.xmpp.user.shard1.DISABLE_CERTIFICATE_VERIFICATION=true
org.jitsi.videobridge.xmpp.user.shard1.IQ_HANDLER_MODE=sync

org.jitsi.videobridge.octo.BIND_ADDRESS=10.15.0.21
org.jitsi.videobridge.octo.PUBLIC_ADDRESS=65.100.69.100
org.jitsi.videobridge.octo.BIND_PORT=4096
org.jitsi.videobridge.REGION=region1

org.jitsi.videobridge.rest.jetty.tls.port=4443
org.jitsi.videobridge.rest.jetty.sslContextFactory.keyStorePath=/etc/jitsi/videobridge/wildcard.jks
org.jitsi.videobridge.rest.jetty.sslContextFactory.keyStorePassword=testpassphase
org.jitsi.videobridge.rest.COLIBRI_WS_DOMAIN=jvb1.domain.com:4443
org.jitsi.videobridge.rest.COLIBRI_WS_SERVER_ID=jvb1

If we would like to upgrade JVB to 2.1-314. Do we have to add this to our configuration?

org.jitsi.videobridge.rest.COLIBRI_WS_DISABLE=false

And what else do we have to modify on our current configuration?

Yes.

Does this line still required?

Yes

OK Thank you

Does this apply to the docker distribution as well? Or is there a guide for enabling websockets in docker-jitsi-meet?

EDIT: I guess my question should be rephrased as, does the websockets doc also apply to docker-jitsi-meet?

I don’t think Docker has been updated to use the new config file yet, so if you have a working websockets install, you’ll just need to add org.jitsi.videobridge.rest.COLIBRI_WS_DISABLE=false to the sip-communicator.properties file.

1 Like

This post was flagged by the community and is temporarily hidden.