SCTP channels deprecation, use websockets!

We are deprecating the SCTP Webrtc Datachannels and recommend migrating your deployment to use websockets. At some point support for SCTP will be dropped from the project.
We had migrated the default deployment from now on to use that by default for new installs ( jitsi/jitsi-meet#7781 and jitsi/jitsi-videobridge#1462). As of today(2020-09-25) this is only in unstable, but soon will be in the stable repo.

There is a document on how to do the migration here

With this change, we no longer by default use the multiplexing in nginx based on ALPN as it proved to be problematic in a few scenarios. The TURN server now just uses default ports (3478 and 5349). If someone wants to run it on port 443 as nginx on the same box we recommend using a second DNS and you can read how to do that here.

3 Likes

I was confused by this; it’s because @damencho is concerned about meet and prosody, and AFAIK don’t work on videobridge.
However this was pinned by @bbaldino, and that’s the relevant point.

Websockets in Jitsi-meet can be enabled at 2 levels:

  • to allow the client to talk to Prosody
  • to allow the client to talk directly to videobridge.

This announce is only about the exchange client <-> videobridge. For Jitsi devs this is obvious since SCTP concerns only videobridge. It was less so to me.
BTW it’s a bit confusing too that the linked page from the devops guide says:

  # colibri (JVB) websockets for jvb1

jvb1 is probably a typo

for people using statistics, it could possibly impact their scripts;

curl localhost:8080/colibri/conferences/<id conf> | jq

used to return

{
  "contents": [
    {
      "sctpconnections": [

and now it will return

 {
  "contents": [
    {
      "channels": [

Yep, this is true.

I’d amend this slightly. contents always returned whatever was there, which previously, when using data channels, would have included both channels and sctpconnections. With sctp removed, the sctpconnections won’t show up anymore (since there won’t be any) but channels will be there as before.

I’m very confused… It’s breaking change, I have project with lib-jitsi-meet and at some morning it broke.

Ok, you deprecated the SCTP Webrtc Datachannels. But I don’t want to use websockets (I have some reasons and techical limits). Can I somehow create the new RTCPeerConnection manually (with my STUN or TURN server) and there create RTCDatachannel without websockets?

Are you using meet.jit.si deployment with lib-jitsi-meet?

Yes, I am

Yep, this had already been disabled there. When using meet.jit.si you should be using config based on the current https://meet.jit.si/config.js and there it is openBridgeChannel: 'websocket',.

1 Like

Thanks for this update.
Any idea when it will be in a stable repo?
I need to decide whether I should wait till stable release and install later,
or
Install now and migrate

I @damencho , does the SCTP Webrtc Datachannels deprecation means the STCP channels part will be remove from the videobridge code ?

We recently find that in some case, websockets are unusable for example when users are behind some proxy (I’ve test it in our platform with a basic squid proxy installation).

If STCP is removed from videobridge, you’ll remove a fallback mechanism for client to bridge communication when the websocket are blocked.

Regards,
Damien.

Yes the plan is to drop the support for those completely

I wonder why would the websocket not work, this means in that environment meet.jit.si will not work at all as it uses websockets instead of bosh.

Yes you’re right with this proxy environment XMPP over websocket didn’t work and meet.jit.si is not working.
I know that it is possible to enable websocket support with squid (cisco-squid-wss.pdf) but it require some specific configuration and end user can’t really understand it.
I’m going to add a websocket test in our platform to see if it’s a real user scenario and how it’s affect our users.