Shmoop
March 11, 2021, 8:20pm
#1
We recently incorporated the latest version of the Jitsi codebase and it came with the switch from data channels to web sockets. However, we are running into issues with web sockets (see here Websocket channel closes when connection interrupted ) and would like to revert to using data channels. When we were using data channels previously to send messages, we had zero issues.
To revert to data channels, we tried going into the config.js file and changing the openBridgeChannel value to datachannel. However, this didn’t seem to fix our issue, and when we check our console logs all the same messages still appear which are related to websockets. So this tells me that we are still on websockets and maybe there is something else we need to do to make the change.
Appreciate any help we can get here!
This is how websockets are enabled.
# Introduction
WebSockets can be used instead of WebRTC Data Channels for transport of Colibri
client-to-bridge messages. This needs support from the bridge as well as the
client.
When this is enabled, a bridge will advertise a Colibri WebSocket URL together with
its ICE candidates. The URL will be specific to an endpoint (in fact the ICE username
fragment is reused, encoded as a URL parameter, for authentication), and connections
to it will be routed to the Endpoint representation in the bridge.
The URL has the following format:
```
wss://example.com/colibri-ws/server-id/conf-id/endpoint-id?pwd=123
```
# Bridge configuration
To enable WebSockets on the bridge, both the publicly-accessible HTTP server and WebSockets
themselves must be enabled.
The following block in jvb.conf configures the publicly-accessible HTTP server:
This file has been truncated. show original
You can try to reverse-engineer to revert.
Shmoop:
To revert to data channels, we tried going into the config.js file and changing the openBridgeChannel value to datachannel. However, this didn’t seem to fix our issue, and when we check our console logs all the same messages still appear which are related to websockets. So this tells me that we are still on websockets and maybe there is something else we need to do to make the change.
You need to enable sctp in jicofo if it is not … jicofo/reference.conf at 069d876504a4d7ce6456fc51706c43cf2424a6c4 · jitsi/jicofo · GitHub
Hi Damencho,
Can we just add that one value to jicofo.conf or should /etc/jitsi/jicofo.conf replace /etc/jitsi/sip-communicator.properties ?
We install using sudo apt-get install jitsi-meet -y
This install method does not configure /etc/jitsi/jicofo.conf, instead if configure sip-communicator.properties.
cd &&
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add - &&
sudo sh -c “echo ‘deb https://download.jitsi.org stable/’ > /etc/apt/sources.list.d/jitsi-stable.list” &&
sudo apt-get -y update
sudo apt-get -y install debconf-utils
sudo cat <<-EOF | sudo debconf-set-selections
jitsi-videobridge jitsi-videobridge/jvb-hostname string $FQDN
jitsi-meet jitsi-meet/jvb-serve boolean false
jitsi-meet-prosody jitsi-videobridge/jvb-hostname string $FQDN
jitsi-meet-web-config jitsi-meet/cert-choice select I want to use my own certificate
jitsi-meet-web-config jitsi-meet/cert-path-crt string /etc/ssl/fullchain.pem
jitsi-meet-web-config jitsi-meet/cert-path-key string /etc/ssl/privkey.pem
EOF
sudo apt-get install jitsi-meet -y
sip-commucator values are with higher priorities, bot config files can work together with no problem for now.
Shmoop
March 11, 2021, 9:53pm
#6
Thanks for the quick response.
Just tried that, and still same issue.
To be clear, we did the following:
Followed your instructions to enable sctp in jicofo config
Edited config.js file to include openBridgeChannel: ‘datachannel’
However, when I go to test it, I still have the same issue, and console log clearly references web sockets.
Attaching 1 screenshot to show the changes in the config files and the second screenshot to show the console log
Are we missing anything?
1 Like
Shmoop
March 11, 2021, 10:40pm
#8
That worked! You’re a genius!!!
For anyone else following, here are the four places to edit to revert web sockets to SCTP data channels:
Enable sctp data channels in jicofo config jicofo/reference.conf at 069d876504a4d7ce6456fc51706c43cf2424a6c4 · jitsi/jicofo · GitHub
Change jitsi-meet config. In /etc/jitsi/meet/your-conf-config.js
make sure you have: openBridgeChannel: 'datachannel',
Disable websockets in videobridge config jitsi-videobridge/reference.conf at 8466e69e1bc3a98c051731948be2f14bff639b29 · jitsi/jitsi-videobridge · GitHub
Enable SCTP data channels in videobridge config jitsi-videobridge/reference.conf at 8466e69e1bc3a98c051731948be2f14bff639b29 · jitsi/jitsi-videobridge · GitHub
Restart jicofo and jvb services
Thanks for all your help @damencho - super appreciated!!
2 Likes
THanks you shmoop.
Enabled sctp data channels in jicofo config.
Added following lines in file /etc/jitsi/jicofo/jicofo.conf , just below “jicofo {”
sctp {
enabled = true
}
Added Following lines in /etc/jitsi/meet/meet.example.com-config.js, just below “var config = {”
openBridgeChannel: ‘datachannel’,
Modified file /etc/jitsi/videobridge/jvb.conf as following to disable websockets
websockets {
enabled = false
# domain = "meet.example.com:443"
# tls = true
}
Added following lines in /etc/jitsi/videobridge/jvb.conf just after “videobridge {”
sctp {
enabled=true
}
Websockets are disabled and SCTP is working perfectly.
This may not work in latest jitsi. It is working as of Today in latest stable.
1 Like