Screen sharing not working due to bandwidth problems

Hello,

On sharing the screen, sometimes people in the meeting can’t see it. This happens even when videoconferencing with just two people.

I looked for information in the logs and I saw some messages related with bandwidth allocation problems:

JVB 2021-06-10 13:17:48.632 INFO: [66] [confId=9399feed112f7aa5 epId=11579991 gid=932 stats_id=Wilmer-4QG conf_name=room1@conference.call.domain.com] BandwidthAllocator.allocate#361: Endpoints were suspended due to insufficient bandwidth (bwe=-1 bps): bc9fa4d3

As you can see, the bandwidth estimation is negative: bwe=-1 bps which seems weird. I feel that could be why people at the meeting can’t see my screen.

I read this thread: Jitsi-meet-docker Server bandwidth - #32 by qwerts89 and disabled BWE in videobridge config:

    http-servers {
        public {
            port = 9090
        }
    }
    websockets {
        enabled = true
        domain = "call.domain.com:443"
        tls = true
    }
    cc {
        trust-bwe = false
    }
}

Then, people in the meeting can see my screen. I tried with useNewBandwidthAllocationStrategy: true, instead of trust-bwe = false but that didn’t work (people didn’t see my screen).

More info:
Debian 10 Buster (LXC container)
VideoBridge version: 2.1-492-g5edaf7dd-1

Regards,

Yes, this is the problem… Are you using a custom client?

The useNewBandwidthAllocationStrategy: true is a config.js (client side) parameter, but from how you word your sentence I have the feeling that you changed it in the jvb.conf. If that’s the case, can you try again by changing it in config.js?

@gpolitis I appreciate your answer.

I’m not sure about where to add the useNewBandwidthAllocationStrategy: true option. I have the following config.js files:

/etc/jitsi/meet/call.domain.com-config.js
/usr/share/jitsi-meet/interface_config.js
/usr/share/jitsi-meet/logging_config.js
/usr/share/jitsi-meet-web-config/config.js

I think the file to edit is the first one, so added this to it:

var config = {
    // Connection
    //

    useNewBandwidthAllocationStrategy: true,

    hosts: {

Then, I removed the trust-bwe = false from the jvc.conf file and restarted the jitsi-videobridge2.service. Nonetheless, with this set up I couldn’t share my screen. The other people in the meeting only saw a grey background and no image al all.

This is the one

EDIT: Just make sure you don’t have the same config param twice, i.e. if the param is already present in the file, just change its value.

Hi!

I made sure there was just ony on line with useNewBandwidthAllocationStrategy: true,. This is the config file:

var config = {
    // Connection
    //

    useNewBandwidthAllocationStrategy: true,

    hosts: {
        // XMPP domain.
        domain: 'call.domain.com',
        anonymousdomain: 'guest.call.domain.com',
../..

However, It didn’t work. I’m using both Firefox and Chrome as clients to join the meeting. I’m connected to the Internet through optical fiber, with a symetric 600 Mbps line.

I am not sure what’s going on (yet), but I think we’ll get to the bottom of it. One thing that’s strange to me is the domain that you’re using, I would assume that call.domain.com is not properly routed (unless you have custom DNS settings or using a custom DNS server). Is there a public URL that I can actually check your config file looks correct?

Sorry about that. I disguised the domain name to hide the real one. How would you check my config file looks correct? Does the browser receive it?

Yes, the client configuration that is stored in config.js is public knowledge and the client retrieves it from https://yourdomain/config.js. For instance, you can check our client configuration here for meet.jit.si. We don’t store any sensitive information there.

Going back to that previous question, actually bwe=-1 at that particular place means that adaptivity is disabled (i.e. trust-bwe is set to false). I think we need to start troubleshooting from scratch because the scenarios may have been mixed? It would be great if you could:

  1. grab your client bridge and jicofo configuration (there you should really redact the connection parameters).
  2. Repro the issue
  3. Share the jicofo and jvb log files to see exactly what’s going there