Video switch off for everyone when in JVB or TURN mode, audio still connected (2 last stable builds)

Hello !

I have an issue in the latest builds which should be pretty simple to resolve but I can’t manage to find the solution.

I have the following environment :

jicofo-1.0_954-2
jibri-8.0_114_g20e233e-2
jitsi-meet-web-config-1.0.6776-2
jitsi-meet-web-1.0.6776-2
jitsi-videobridge2-2.2_9_g8cded16e-2
jitsi-meet-tokens-1.0.6776-2

And I managed to make it work (P2P, TURN and JVB works depending on the situation).

In P2P mode with 2 participants, everything works as expected.

In TURN or JVB mode (depending if ports are opened or not), the video nearly instantly cuts when switching from P2P mode to another mode. I say instantly because I still have a single frame displayed in the new participant window joining the room, then video cuts off for everyone.

It should be something related to performance settings because I still have audio so it still communicates in the channel but I can’t manage to find what.

In server logs, JVB says the usual Selected pair, ICE connected, Pair succeeded etc… No errors on this side

In browser console it is the same, I have nothing related to stopping the video transmission because of some quality settings, it says adding and creating the remote track, ICE connected JVB (in JVB mode), send ICE candidate, data channel opened, sending constrainsts and nothing more like it usually does.

Do you have any idea on how to troubleshoot this issue ?

Thank you !

Is there the same issue if you disable P2P mode completely and host the meetings always on JVB?

Yes it goes through JVB now with 2 participants, I do have audio and I don’t have video. Except sometimes some frames at the begining so the video is able to go through the channel but something prevents it

Is the websocket to the bridge working? Any errors in the js console?

I have websockets disabled for networking reasons, which has always worked well in the past. Do you think it could be related ?

Any errors in the js console?

Not really, you can see at https://gofast-preprod-comm.ceo-vision.com/jitsi-meet if you want !

If you try take care to don’t have :4443 in the URL, sorry I have this port opened for some testing and see you are accessing it

What is your jvb config?
Seems you don’t have websocket configured in the bridge.

Yes we have disabled websockets a long time ago but until now it has always worked, I can try to get it back to see if this is the issue

sip conf

org.ice4j.ipv6.DISABLED=true
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=10000
org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true

org.jitsi.videobridge.xmpp.user.xmppserver1.HOSTNAME=gofast-preprod-comm.ceo-vision.com
org.jitsi.videobridge.xmpp.user.xmppserver1.DOMAIN=auth.gofast-preprod-comm.ceo-vision.com
org.jitsi.videobridge.xmpp.user.xmppserver1.USERNAME=videobridge
org.jitsi.videobridge.xmpp.user.xmppserver1.PASSWORD=xxx
org.jitsi.videobridge.xmpp.user.xmppserver1.MUC_JIDS=JvbBrewery@internal.auth.gofast-preprod-comm.ceo-vision.com
org.jitsi.videobridge.xmpp.user.xmppserver1.MUC=JvbBrewery@internal.auth.gofast-preprod-comm.ceo-vision.com
org.jitsi.videobridge.xmpp.user.xmppserver1.MUC_NICKNAME=videobridge
org.jitsi.videobridge.xmpp.user.xmppserver1.DISABLE_CERTIFICATE_VERIFICATION=true

videobridge.conf

videobridge {
    health {
        interval = 300 seconds
    }
    cc {
        trust-bwe = false
    }
}

But websockets are used for signaling, and we can easily see that the signaling works well here

Nope, there is a websocket for communication between the client and the bridge.

This is the default jvb config file when installing.

Yeah I see we had to disable the configuration due to screen sharing error in chrome

In the past we used this documentation :

But this communication is still to send messages between the client and the bridge to establish the communication right ? Not the audio/video stream itself.

And I can see in videobridge that the communication is established, I have the audio and as I said before sometimes we see some frames goes through the video channel so I’m pretty sure this is not related

I cannot reproduce the problem on my instance.

Can you try matching the configs from meet.jit.si:
https://meet.jit.si/config.js

The videoQuality part

Yes sure let me try

But that communication is very important requesting the videos to be delivered, the resolution to be sent etc. For example, when that communication is broken there is no screensharing.

1 Like

Sure and that’s why we removed it so (I don’t remember the details) it uses prosody to communicate with the bridge and it works well like that. It’s maybe less performant I saw some entries about that in forums but it works in our environment (which is a bit specific I have to admit).

Anyway if the .js conf doesn’t work I will try to enable again websockets

Our files are pretty identical now but the behavior is still the same unfortunately.

I will try to use jvb websockets and see

There are also some CORS and 404 errors when I check your server. Do you publish Jitsi using a subfolder?

Yes we are using subfolders and already resolved the related issues, there is still 2 404/CORS errors which are related to language and manifest.json, I can solve it easily but it always has been like that.

You can see the behavior in our production platform is the same (https://gofast-comm.ceo-vision.com:443/jitsi-meet)

Well I’m running into an infinite “pending” wss request with an nginx 499 error with websockets.

I won’t have time to inspect more unfortunatly so I will stay on the old version in production and wait to see if future updates of videobridge fixes the issue or try to inspect more on this later in january.

Thank you for your time, will keep you updated !