Disable BWE

Hi, i would like to know if there is an impact when we disable BWE.

I had to disabled it that since some participants with low bandwith but also good bandwith got issue with it.

Does it creates some unexpected or dangerous issues.

Yep, if someone had problem with internet you will keep sending and getting stuff lost and the client send packets to request frames that were lost so basically will produce more and more traffic shooting down its own internet even more …

1 Like

Good to know, so basically its a really bad thing to disable BWE as i read. We had to do that since we got blackscreen for some users and disconnected user with the bwe warning. Do you have any recommendation or settings to make BWE less strict and avoid kicking people.

Not really, what are the browsers having the problem?

We were fixing stuff for Firefox and wrong bandwidth estimations … but I think there are still issues there and we are waiting for the Mozilla team to push a fix.

1 Like

i dont remember exactly, but i guess it was under chrome.

Im affraid about the algorithm used behind. For example, we choosen to scale horizontally JVB with lot of small instances with constrained network (250MB) and to split conferences on a lot of JVB using OCTO with stress parameters.

Could we be impacted by the algorithm ? Or its not based on the server side specs to make an estimation that can be wrong if split is ignored

Do you see many bridges in one conference?

Can you try the same scenario same people on meet.jit.si and if you reproduce it, can you send me in private message the meeting link and approximate time of it, this may help to debug it. Thanks.

1 Like

on our side yes we have many bridges in one conference , we try to split a lot since its small instances. i will try to reproduce it on meet.jit.si but i guess its hard

Or its not based on the server side specs to make an estimation that can be wrong if split is ignored

The estimation is a realtime thing, it doesn’t need to consider server specs or anything like that. It’s simply: if packets are being lost, then capacity is exceeded, and we should lower our sending rate. If packets are not being lost, maybe we can try increasing our sending rate slightly (if we are not already at the maximum).

It will react appropriately if your server bandwidth is congested as well as if one client’s bandwidth is congested. Of course, if your server bandwidth is congested, the lower BWE will affect all users…

If you know you have limited server bandwidth, you can consider lowering the maximum bitrates and/or resolutions to try to stay within your available bandwidth with your expected number of participants.

1 Like

interesting and what about users split with OCTO ? considering we have 250MB for network

considering 1 user = 5MB and 1 JVB = 1 vm

we can say 50 users max per JVB / VM .

Does the server bandwith will be congested if we split users on differents JVB with OCTO ?

For example, lets say in a single conference with 60 users we have 8 Videobridge with 250MB for each

@damencho I tried to reproduce on meet.jit.si without success currently but it seems really hard since i dont know what was the exact conditions to reproduce and we also have specific environment with Turn server …

I have the same problem. But the worst thing is that it happens with the jibri since it reaches a point where the video is gone and only audio is heard, in a scenario with a recording of 2 hours at once it remains in only audio, no reconnection retries are seen, I had video losses of 1 hour and in other cases of half an hour. It should be noted that it is a server with a unique job and its bandwidth is 200mb / s. The truth is that in the May version that problem did not occur. I think it is a problem with the bandwidth estimation. But I can’t go back to the previous version since there were other worse problems and only occasionally does this problem occur to jibri.

You need to count and the octo traffic. I’m sending to that bridge, but if someone on the other bridge needs my HD layer, the bridge will send the video to the other bridge.

1 Like