Video feed gets disconnected

Hi,

We are using jitsi release version stable-7439 and installed it using the self hosted guidelines on our private cloud.

All necessary ports of the various jitsi components are open and routed via port 443 in our firewall. We do not have any NAT connecting our cloud setup to the external internet.

Our problem is that, when more than 1 user joins a conference in jitsi, the video feed is dropped. Neither the participant can see the video feed of others nor other participants can see the video feed of other participants in the conference. Audio feed is available but sometimes, it drops too.

Mostly on jitsi meet, the tile view of the participant is only visible with the initials of the participant’s name in the tile and the signal quality shows that the connection is lost. But no participant is kicked out neither it is shown that on the jitsi meet UI that video has been paused due to low bandwith.

There are no errors in the logs of prosody, jicofo while JVB logs says that endpoints have been dropped due to low bandwidth.

Any suggestions on what might be wrong? I could share some of our jitsi component configurations if that helps.

Can you please share the browser console logs?

meet.eu.videoconf.cloud-1661514552988.log (34.9 KB)

Is port 10000 UDP firewalled on your server by any chance?

With the same participants do you reproduce on meet.jit.si?
What is the cloud bandwidth of that machine?
It can be bandwidth problems on the server.
How did you install the packages? You installed the debian packages?
Is that applied on your jvb machine jitsi-videobridge/20-jvb-udp-buffers.conf at master · jitsi/jitsi-videobridge · GitHub ?

We have routed IDP via port 30000 which is also accessible via our firewall. That’s the only non standard port configuration that we have in place. Sorry for not clarifying it earlier.

Ignore that. I think I have mixed up reports and this is not relevant at the moment.

Is jvb configured to listen to port 30000, are you sure that the NAT port forwarding works and packets reach jvb?

This is an excerpt from our jvb.conf

videobridge {
    ice {
        udp {
            port = 30000
        }
    }
}

The only visible difference between out cloud jitsi setup and meet.jit.si is, connection quality for all participants is always poor/low as displayed in red in jisti meet web UI in our jitsi setup while on meet.jit.si its good and shown in green.

Any particular log statement on JVB that would signify that packets are reaching the JVB on port 30000?

Yeah, apparently I’m confused here by the previous comments.
So a 3 way call works, so it is not a port issue. It is the quality. So if the same clients you are testing your deployment works with meet.jit.si than this is not a problem on the client side network.
When you are in a meeting with at least 3 participants, wait for a minute and check your local stats.
What do you see about bitrate and packetloss:
image

What about the other participants?

If you see the videos in a 3-way call, this means jvb is reachable.

Yes, the videos are available for a few seconds on on a 3-way call.

So, when multiple participants join these are the sequence of the connection qualities for everyone in our setup:

  1. On initial joining, the connection quality is good indicated with green signal icon with video content visible
    Screenshot 2022-08-29 at 16.31.40
    Screenshot 2022-08-29 at 16.38.28

  2. 2-3 seconds after joining, the connection quality is poor indicated with red signal icon with video content visible
    Screenshot 2022-08-29 at 16.26.31

  3. Connection quality then turns to either lost with no video content and remains so
    Screenshot 2022-08-29 at 16.29.52

  4. Connection quality then turns to either inactive with no video content and remains so
    Screenshot 2022-08-29 at 16.31.08

For me, this indicates that something between the client and the server stops the UDP packets … not sure what is that …
If you have seen the video even for 2 seconds, this means the setup is working, the clients are able to send packets to the bridge and the bridge is able to route it to the other clients.
So seems like a network problem on the way between clients and jvb…

We constantly get this in the JVB log

JVB 2022-08-31 12:00:36.916 INFO: [123] [confId=4cbad9e967e9845f conf_name=0110b574-2400-4d51-a5b4-ff4f83943049@muc.meet.jitsi epId=187faa44 stats_id=Donnie-t3E] BandwidthAllocator.allocate#379: Endpoints were suspended due to insufficient bandwidth (bwe=1753588 bps): 7353dd55,5b40a75b,ecf680ef

Would fine tuning the BWE algorithm parameters in jvb.conf provide any relief to our issue?

We consider the defaults to have a good performance in general. You can play with that, for sure that will change the behavior and you may not see the suspension but you may sometimes see overloading the links …

We tried to trace the UDP calls between JVB on our private cloud and host machines on external network and found that the length of the UDP packet from JVB to client machines are very very small (5-10%) when compared to the length of UDP packets sent from the client machines to JVB. Is this expected?

Probably if it detects low bandwidth and is forwarding just the low layer.