Jitsi on mobile internet 3g hsdpa vs google meet)

A question about working at low speeds with latency.
Testing work on the mobile Internet 3G HSDPA (3mbps/1mbps >50ms)
our test lab:
2 laptops, the first is connected via wifi 5Ghz, the second via 3G mobile Internet
We turn on the camera only on a laptop with 3G:
When making a p2p call, the resolution is from 180p to 720p with traffic consumption up to 1 megabit in peaks.
When p2p is disabled (in the config, or just by connecting the 3rd client to the call), the resolution drops to 180p with no chance of a return.
The issue is reproducible on our latest stable server,
reproducible on meet.jit.si and beta.meet.jit.si servers.
For the experiment, I checked the work of meet google under the same conditions - it quietly dynamically changes the card on the same channel with some kind of magic despite the number of participants.
All settings are identical to the public server (vp9, simulcast etc)

Is that a screen-share or the camera?

1 camera only on one client (muted, no screen-share)

Then it should ramp up to 360p at least I reckon.

@Jonathan_Lennox maybe you can help debug this?

there are no errors in the logs. Only if there are problems with communication at all, you can get errors of lack of bandwidth

Can you check if the reslution drops between the sender and the server, or between the server and receiver. I suspect the former, because the sender is on 3G. Can you look around in chrome://webrtc-internals to see if you spot any interesting differences between the p2p and bridge case? Specifically anything related to bandwidth estimation.

reduces sender flow due to supposedly low bandwidth


FrameWidth 1280
frameHeight 720
framesPerSecond 11
framesSent 5888
[framesSent/s] 11.011012840000104
hugeFramesSent 16
totalPacketSendDelay 844.661
[totalPacketSendDelay/packetsSent_in_ms] 169.9166666666656
qualityLimitationReason none


frameWidth 320
frameHeight 180
framesPerSecond 23
framesSent 11091
[framesSent/s] 23
hugeFramesSent 111
totalPacketSendDelay 1673.121
[totalPacketSendDelay/packetsSent_in_ms] 9.526315789473795
qualityLimitationReason bandwidth
qualityLimitationDurations {bandwidth:611.948,cpu:0,none:318.729,other:0}
qualityLimitationResolutionChanges 80

did some additional testing:
turn off the simulcast - the quality and resulution without p2p rises, but switching the quality of 180/360/720 only affects the resolution - the traffic from the sender always remains static more than 1 megabit (in reference conditions on wifi)

This confirms that the limitations is the sender->server bandwidth, which is somewhat surprising because the calculation performed by the sender. The receiver, whether it is our bridge or the other laptop in p2p, just sends feedback about the packets that it received.

I don’t understand what happened when you turned off simulcast. Is it comparable to p2p or different?

Can you select the “legacy” mode in webrtc-internals (the drop down menu at the top) and look at the “bweforvideo” graphs? This will show the transmit bitrate and bandwidth estimation over the last 5 minutes.

disabled simulcast works as p2p (even with 3 clients in call)
when simulcast is enabled, the graph does not display anything.
In this test, the traffic is approximately the same everywhere.
With all tests, the camera is turned on only on 3G Internet.
In all tests, we see approximately the same channel utilization (through the same task manager).
In all tests, the channel speed rating is also approximately the same, either a red icon or a yellow one.
In worst case on p2p (or disabled simulcast) we met the frame rate drop to 6fps, but the resolution remained at the level of 720p

  1. p2p test - the resolution did not fall below 720p in 5 minutes
  2. 3 clients (one is broadcasting, two are watching) simulcast is on, the resolution has not risen above 180p
  3. 3 clients (one is broadcasting, two are watching) the simulcast is off, the resolution has not dropped below 720p.

repeated the test on a public server.
p2p gives a larger channel, the picture does not fall, when working through jvb the channel is clearly smaller, the picture often drops to 180.
But all the same, under equal conditions for estimating the channel without a simulcast, it is quite realistic to get 720p from a 400kbs channel

update: my server without simulcast resolution during this call sometimes dropped to 180p, but in most cases was 720p-540p.
So my question - is it possible to get similar work with simulcast on resolution with same bandwidth