This message was deleted.

It is usually due to congestion. It could be either upstream congestion or downstream (server -> client) congestion. Can you provide details on what kind of network does not work well? If up stream is congested, client will publish lower bitrate/lower quality video to fit in the available channel capacity. Down stream congestion means server will pick a lower layer (if the track is simulcast) to fit within the available down stream channel capacity.

I don’t know too much about the network. Tomorrow I’m visiting people who are in this network and I’ll be able to learn more. I just wonder how to measure all these things like congestion. Do you use any specific tool at LiveKit? Other than webrtc-internals?

WebRTC (the core tech which is used by LiveKit) has algorithms to do it. You can use a standard speed test like https://www.speedtest.net/ to measure available bandwidth from a client machine. But, real time audio/video has different requirements (jitter is as important as the available bandwidth). So, a high bandwidth measurement is a test like the above does not automatically guarantee great quality all the time. If you are familiar with chrome://webrtc-internals (that is the details stats available in Chrome browser), you can check how much the client/server is estimating for bandwidth.

@high-exabyte-20673 do you have IPv6 turned on on these servers? we've noticed that it makes a difference especially for users on mobile networks

@dry-elephant-14928 You mean the servers where we host livekit?

On behalf of David, yes, server side IPv6 support.

No, only IPv4 is used.

That's what David was referring to. There are certain mobile networks that do not allow IPv4 (or actually send IPv4 probably though some proxy which does not work well). If the problems you are seeing are with mobile networks especially, enabling IPv6 on the servers and let the connection happen purely over IPv6 might provide better quality.

Hmm, the problem I’m investigating occurs on windows desktops.

Then it could just be poor network or under powered machines.

Looks like one machine is under powered 😛

Is the switch happening in up stream or down stream? The subscribed video layer will change for two reasons 1. Down stream congestion 2. Up stream congestion - this is when browser will detect congestion and stop/resume layer to adjust to channel capacity. Server will detect this and switch the layer going to the subscriber to the best available layer coming from publisher. For case 2, browser is in control. For case 1. there is no way currently to have that level of control. You can disable congestion control completely (https://github.com/livekit/livekit/blob/3f9f3adf91a2b296a5934970ca493754c8639314/config-sample.yaml#L68). That will prevent layer switches due to down stream congestion. But, it will also stop adaptation to down stream congestion.

Thank you @fancy-wire-61616. That may be helpful in my case. So if I turn congestion control off, then downstream layers will only be controlled by the size and visibility of video elements in the browser?

yeah, if you have

adaptiveStream

enabled. Or you can explicitly subscribe to whatever layer you need from the subscriber side.

I’ll try to turn the congestion control off then.