WARNING: Active socket already initialized

Sometimes we have trouble with connection errors and ghost users on our jitsi server (ubuntu 18.04, installed without problems with the official self hosting guide). So I’m trying to figure out the reason.

Every time a partificant joins a meeting we get an WARNING error in jvb.log:

2021-03-13 14:46:40.113 WARNING: [209] [confId=4653f4cf22c2f8bb gid=42618 stats_id=Haskell-4CZ componentId=1 conf_name=testroom01@conference.meet.our-server-name.de ufrag=ftolu1f0ltdgml name=stream-0b9bc971 epId=0b9bc971 local_ufrag=ftolu1f0ltdgml] MergingDatagramSocket.initializeActive#599: Active socket already initialized.
Got sctp association state update: 1
sctp is now up. was ready? false

And every time a partificant leaves a meeting we get this error:

2021-03-13 14:47:16.212 WARNING: [215] [confId=4653f4cf22c2f8bb gid=42618 stats_id=Haskell-4CZ componentId=1 conf_name=testroom01@conference.meet.our-server-name.de ufrag=ftolu1f0ltdgml name=stream-0b9bc971 epId=0b9bc971 local_ufrag=ftolu1f0ltdgml] MergingDatagramSocket.doRemove#349: Removing the active socket. Won’t be able to send until a new one is elected.

Since the level of these messages is WARNING and not INFO, I suppose that we should change something in our configuration? What could be the reason for these messages?

sctp for data channels between jvb and clients is deprecated and has even be removed for recent versions. You should use websockets instead.

Thank you very much.

I’ve tried to activate websockets, but it doesn’t work.
Everything in the documentation you’ve referred was already configured except openBridgeChannel: 'websocket', in /etc/jitsi/meet/our-server-name-config.js
So I’ve added this line and restarted jitsi-videobridge2.
But the WARNING messages are still the same.

Since sctp is deprecated, I’d assume that on a new jitsi installation websockets should be activated.
So I’ve installed today a new test-server using the self hosting guide, but the same here:
Got sctp association state update: 1
sctp is now up. was ready? false

I don’t know what I’m doing wrong? I’m using the stable channel.

@hb6862 since you said you followed the Self-hosting guide, is it safe to assume you have all the components installed on the same server? So, Jitsi meet, Jicofo, Prosody AND jitsi-videobridge2 are all on the same server?

do you use 2.0.5390 ? I think (I may be wrong) that with this version you still need to specify JVB websockets in config.js (it’s not necessary in unstable).

Edit: after checking the code, it is very much possible to see log messages about sctp even if using websockets. Sorry for the misunderstanding from my part. You should look in browser console if websocket messages are in error or not, and in the UI if after enabling websockets if features using them (such as dominant speaker, the blue rect around a vignette) are effective.

Yes, all components are installed on the same server. The versions are:

dpkg -l | grep jitsi
ii jitsi-meet 2.0.5390-3 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.4628-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-turnserver 1.0.4628-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.4628-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.4628-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-416-g2f43d1b4-1 all WebRTC compatible Selective Forwarding Unit (SFU)

Here’s a screenshot of the network monitor > websockets. Since I’m looking at this information for the first time, I’m not sure what it says but it looks like I’m using websockets and it’s working properly?

It is interesting that the websocket info in the browser is the same regardless of whether the line openBridgeChannel: 'websocket', exists or not. I’ve tested both scenarios. So websocket seems to be the default if the line is missing?

And yes, the blue rectangle for the dominant speaker works as expected.

‘connection upgrade’ means that websocket exchange between station and Jvb occurs, and it seems to work. So I think your sctp messages are unrelated to your problems - that may not be software problems, but actually network reliability problems, with connection timeouts that you could possibly reduce to have ghost connections last less. Off the top of my head I don’t remember how it’s configured unfortunately.

Sorry, I missed the Messages tab. There are some messages marked with a red exclamation mark:

And on the Timing tab a red message:

Are these ok?

Of course, you’re right: The problems we have can be a network problem.
But first I wanted to be sure that the WARNINGs in my initial questions are normal or if they indicate a problem. Since these messages are WARNING level and not INFO level I don’t want to ignore them.
So it would be interesting if these messages occur on every self-hosting-guide-installation or not.

these ‘exclamation marks’ look more like arrows to me. Red for incoming, green for outgoing.

I see them in my test setup and I ignore them.

You’re right. I need new glasses :smile:

Ok. Thank you very much. Your help is really appreciated.

In my opinion a warning should indicate a potential problem. So it would be very interesting to know for me why these warnings are in the log and what they do exactly mean or how to get rid of them.

What version of prosody are you using?

you can try to read and understand the code, of course. If your life is long enough, you’ll succeed. Mine is not.

apt list -a prosody
Listing... Done
prosody/unknown,now 0.11.8-1~bionic1 amd64 [installed]
prosody/bionic 0.10.0-1build1 amd64

I’ve updated prosody with the help of this tutorial.

That’s the latest. I wonder why you experience ghosting then…

Sorry @gpatel-fr it was not meant like that. You shouldn’t read the whole code for me. It was a question to the community. Maybe someone else knows the meaning of these warnings. Thank you very much for your help.

I just stumbled on the answer on this forum: to get rid of sctp you have to invalidate it in both config files for jicofo (jicofo.conf) and videobridge (jvb.conf).

  sctp {
    enabled = false
  }

Only removing one of both configs will make meetings to fail.

This is good. I’ve tested it and now the lines
Got sctp association state update: 1
sctp is now up. was ready? false
no longer appear.

Thank you very much!

One last question:

Can you provide a link to the code you refer to? I would be very interested but I can’t find it.

I just did a grep and after looking at the number of lines returned, decided that sctp support was not removed.