Endpoints problem on clean Videobridge setup

Hello Jitsi teams,

After a clean Jitsi install (stable on ubuntu18)
we have a big trouble with Videobridge, in short, starting from 5 participants n conference, jitsi-web stop showing video for several users, So it looks like no video data transmitted from Videobridge to end clients.

JVB logs show many warnings:

  1. a lot of “Endpoints were suspended due to insufficient bandwidth”.
  2. Got sctp association state update: 1 sctp is now up. was ready? false
  3. Removing the active socket. Won’t be able to send until a new one is elected
    Jicofo logs doesn’t contain any errors or warnings, looks fine

We test Jitsi/JVB with next settings:
P2P - disabled
max video resolution: 480p, sd - 360, low 180p
server setup: 24gb mem, traffic-speed 100mbit
dpkg -l | grep jitsi
ii jitsi-meet 2.0.6826-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.5764-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-turnserver 1.0.5764-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.5764-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.5764-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-607-g153f7e4e-1 all WebRTC compatible Selective Forwarding Unit (SFU)
ii prosody 0.11.13-1~bionic1 amd64 Lightweight Jabber/XMPP server

End users use mostly Chrome and Opera browsers and don’t have any problems with Internet speed.

By default this Jitsi version use websockets?
It’s strange, but there are no Websocket requests on Chrome dev console,
and few errors related to peer media (see pic attached)


Any ideas what is wrong with JVB or jitsi components setup?

What is your Java version?

java8

Do you have only one JVB which is on the same host as JMS?

huh ? There is one in full view on your attached screenshot. Select it and click on the Messages tab to see if messages are correctly exchanged, you should see pings every second (and more)

Note: as stated on your screenshot, it is the bridge channel, used by default by clients to talk directly to jvb nowadays (you could disable sctp and it would get rid of these error messages). Don’t confuse it with xmpp-websockets, used by clients to talk directly to Prosody; xmpp-websockets are optional, the default is still Bosh.

Yes, default setup, all jitsi services on one machine.

Yes, I see a lot of ping/bind requests. There are no errors in Messaging

Maybe related in…

Does by default Jitsi use JVB on localhost? I see jvb’ dependencies on Stun in log
is it OK?

> Starting jitsi-videobridge version 2.1.607-g153f7e4e
> JVB 2022-01-24 19:29:51.972 INFO: [20] org.ice4j.ice.harvest.MappingCandidateHarvesters.createStunHarvesters: Using 193.122.0.59:443/udp for StunMappingCandidateHarvester (localAddress=46.148.234.189:0/udp).
> JVB 2022-01-24 19:29:52.109 INFO: [23] org.ice4j.ice.harvest.StunMappingCandidateHarvester.discover: Discovered public address 46.148.234.189:60785/udp from STUN server 193.122.0.59:443/udp using local address [org.ice4j.socket.IceUdpSocketWrapper@1ebb5659](mailto:org.ice4j.socket.IceUdpSocketWrapper@1ebb5659)
> JVB 2022-01-24 19:29:52.109 INFO: [20] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Using [org.ice4j.ice.harvest.StunMappingCandidateHarvester@478c9871](mailto:org.ice4j.ice.harvest.StunMappingCandidateHarvester@478c9871)
> JVB 2022-01-24 19:29:52.110 INFO: [20] org.ice4j.ice.harvest.MappingCandidateHarvesters.initialize: Initialized mapping harvesters (delay=872ms). stunDiscoveryFailed=false

STUN is used to get the external IP of JVB. There is no JVB other than the one you installed.

and what about port #0/udp in logs and 60785? see bellow, is it right setting?
StunMappingCandidateHarvester (localAddress=46.148.234.189:0/udp).
46.148.234.189:60785/udp

Hello,
I’ve played with video resolution settings without bid luck.
Ok, I enforced resolution to 180p. set video ideal, max, min to 180 in jitsi-meet config.
And for conferences for just 12+ users we got a problems with black screens for some participants and a numbers of “Endpoints were suspended due to insufficient bandwidth” or just “closed active socket” in jvb.log
I’m just wondering, how much bandwidth does this 180p scenario use?
I’ve around 1gbit link on server side, so could it be a problem on server or on clients side?

Unless the clients share a connection (or an ISP), it’s unlikely to be a client-side problem if it affects multiple clients at the same time.

Do you really have 1Gbit/s link at the server side or is that just the port speed or some marketing claim by the provider with no actual guarantee backing it up? Do some testing (as discussed in the thread @emrah linked to).

Bandwidth requirements for 10x 180p are pretty low but the most important thing is loss. If (for example) your provider has congested uplinks then you’ll have loss no matter how much bandwidth you try to push through. Low or even moderate loss may not be noticed when e.g. hosting a website, but can be catastrophic for realtime communication.