Facing Video turned off to save bandwidth in jitsi 6173 version (Docker Deployment)

Developers
,
#1

We have been observing this issue for a couple of days now after migrating to jitsi version 6173(docker deployment).

There is a previous thread on this topic in which the users said they are facing this issue in the latest stable also, I am starting this thread explaining our system scenario as exact I can.

In our conference meeting, people (around 10 - 30) are joining with their videos turned on,

  • In this case, some can see the participant’s faces/video (especially on mobile devices), but many others can not see the participant’s video. Also, they see other participants’ status as Inactive.
  • A participant is sharing his screen, and suddenly other participants see the following message

Video for ‘A’ has been turned off due to save bandwidth. As a result, some participants can not see the shared screen anymore

  • if the participant clicks the user, he is now On Stage. At this point, we expect to see his video/ screen share, other participants’ videos can be disabled as they are not on stage. But video off message is shown:

Screenshot 2022-01-09 at 6.04.50 PM
Screenshot 2022-01-09 at 6.04.50 PM1800×1130 64.6 KB

In jvb log: BandwidthAllocator.allocate: Endpoints were suspended due to insufficient bandwidth

Please check the attached screenshot that has log information for bwe:

image_2022_01_10T05_39_44_363Z
image_2022_01_10T05_39_44_363Z807×112 4.12 KB

We are using jvb version: jitsi-videobridge 2.1-538-g062e9f56

Please note that we’ve explored various combinations of these 2 variables trust_bwe, useNewBandwidthAllocationStrategy. And currently the following combination has been set:

  • trust_bwe is set as true
  • useNewBandwidthAllocationStrategy set as false

as jvb is determining bandwidth allocation, we explored in jvb Bandwidthallocator.java class, that it is calculating available bandwidth for participants and not sending any video layer to that participant if not finding it sufficient.

So how can this problem be fixed? also how jvb is calculating client participant bandwidth? An explanation of how available bandwidth is calculated would be really great.
We are getting sufficient bandwidth on our side and clients also reported that they have no network/bandwidth issue and other platforms like zoom/google meet are working properly (might need a lot of testing to claim that).

image_2022_01_09T12_41_11_599Z
This is our server bandwidth.

A point to mention is that we have another setup that is running on jitsi meet version 5765. There no video turned off issue is occurring on stage and on tile view. So, we are assuming it is not bandwidth problem on our end as all works fine in that setup.
But for version 6173 It is occurring too frequently and even in 5-10 users’ conferences, it can be generated.

This is a burning issue in our system for several days now. And need a solution to work with.

Any help and response are highly appreciated.

Thanks in advance.

Problem with simultaneous display of tiles view
#2

Your best bet is to update to a more recent version. If I recall accurately, version 6173 seemed to be the most plagued by this issue. Upgrading to later versions (particularly JVB) fixed it.

#3

Thank you @Freddie. Now the question is If we want to stay in meet version 6173 and upgrade to the latest jvb stable will it be compatible? I mean is it recommended to run different versions of different Jitsi components. and do you suggest jvb latest stable or any higher version that has this issue fixed?

#4

It’s often recommended to upgrade all components together - because in building and testing, they’re all run together. However, it’s not unusual for people to occasionally upgrade specific components, so you can try just upgrading JVB to see. I think the latest stable should’ve fixed it, but you can definitely try the latest unstable - I know that definitely runs better.

#5

hi Freddie. I noticed that this problem still exists in the latest releases, as some users also facing the same.

As far as the forum is concerned, I feel that many are still getting in the latest meet.jit.si also.
We are feeling kind of shaky to change our system to a newer version to deploy for trial, can you confirm if this issue has been addressed or fixed ?

#6

As you have updated to the latest stable, have you tried setting this to true (the default value)? Does it change anything?

#7

The bandwidth is calculated by the client. The client is sending packets probing for bandwidth.

#8

In addition to what Damencho mentioned, I should point out that virtually all the people who reported this issue in later versions (docker) had custom UI and only selectively upgraded. Everything needs to be upgraded. You’d do best to deploy a dev environment to test this in the way you’re using it to confirm. Bandwidth allocation is one of the toughest parts of WebRTC.

#9

ok let us set the variable and test in that way

#10

yes, it is quite challenging, we are diving deep into this bandwidth allocation also. let us test with the higher versions and useNewBandwidthAllocationStrategy as TRUE.

#11

Hey @mustahsin,

As others mentioned, it’s best to upgrade and test with one of the latest stable releases. There were some changes in that area (how clients describe the streams they want to receive, and what the bridge does when it has insufficient bandwidth), followed by multiple fixes in the last few months.

You should set useNewBandwidthAllocationStrategy to true, as this is what we’re running in prod and is best tested right now.

The way the estimated bandwidth is calculated hasn’t really changed recently. The calculation is done on the bridge, and it is based on jitter and loss on the complete path between the bridge and a client. The “server bandidth” you report doesn’t tell us much, as it is across a different path. One thing to verify is that TCC is enabled and used (this is enableTcc in config.js).

Some of the BWE numbers in your screenshot are extremely low (~57kbps). This means that either the bandwidth to one of the clients is very low, or something happened and the link was overloaded (a similar issue was fixed recently).

Boris

#12

Thank you Boris for the insight.

as we mentioned earlier , we have an another setup with jitsi 5765 with same config. there we are not getting this log with Endpoint suspension.

Yes, It is enabled.

#13

hi Freddie. we’ve deployed jitsi version 6433 with all of its components together without any customization. useNewBandwidthAllocationStrategy is set as true as default.
still, after some time, we got the video/screen share Turned off bandwidth issue. So, later versions are also facing the same.
Can we do something in JVB or config, that no matter how low (presuming bandwidth is low even though bandwidth problem doesn’t happen in 5765 version) is the bandwidth, the Onstage Video will be shown to users?

#14

Well, you can try turning off bandwidth adaptation. But note that this is not recommended and it comes with its own issues. To turn it off, add this to your jvb.conf:

cc {
        trust-bwe=false
    }
#15

ok. let us try, we tried with both true and false in the earlier 6173 version.

Can you tell what issue may arise if set to false.

#16

With BWE turned off, you may run into issues with packet losses. When a client doesn’t have sufficient bandwidth, instead of suspending the endpoint when BWE is on, the packets just get lost - which means that not only video will be lost, but audio will also be affected. You’re likely to see this more pronounced with mobile devices and also on wireless connections.