I am having an issue in almost all calls where they start out fine, with like 3000kbps up and down for all callers, then after a few minutes some of them will drop down to 150kbps or less and the call quality becomes horrible. This happens in p2p and non p2p calls.
A refresh of the page will always fix the issue and bring the speed back up with good quality audio and video. Are there any config changes i could possibly make that might fix this? Is it a problem in bandwidth estimations or jitsi version or chrome?
I’am using 3344 in production environment. Compared to 1622 older prod version its better about bandwidth estimation etc… and works much better even at bad network conditions… No such problem as described…
May be you can play with startBitrate, minBitrate within config.js
With Firefox being able to pump double the bandwidth of chrome though, I’m not sure how far i will get with that as a fix. However I will give those values a try in my config after I update to latest version if that brings no speed increases to Chrome.
I’m still seeing the problem today. And I think the point is that if FF can send 720p no problem, then the line is good – or good enough. So that puts the problem squarely on either chrome, or how the jitsi client code is interpreting/responding to chrome.
I’ve just recently dealt with 5 repro scenarios where the client pushed bandwidth down below 100kbps. Yes, there was some packet loss, but not enough to warrant a reduction to 100kbps! Speedtest showed 1.1 mbps available.
Turning off TCC and REMB resulted in awesome quality on all repro cases.
I’m thinking of just integrating a little speedtest while clients are joining and trusting that speedtest over TCC – but that adds a different risk–the risk of truly changing conditions.
Haven’t tried the mobile apps… I’m focusing on desktops at the moment.
In almost every circumstance where i am seeing low bandwidth and low video quality, the client and server both have very adequate available bandwidth determined via iperf hosted on the hosting jitsi server.
I’m seeing the same thing. I’ve seen it happen in P2P and JVB scenarios, so the problem probably isn’t the bridge. In my opinion, either TCC is broken or Jitsi’s use of TCC is. So many people praise TCC, however, that it makes me suspect the problem is the way TCC is being used. Bottom line, there’s some kind of feedback loop that ratchets down bandwidth, and it’s bad.
Yeah, seems like i will get some horrible quality and dipping into the low 100kbps, i refresh and its back up to 2-3mbps. after awhile it just shoots back down. Refreshing always brings back quality for me though temporarily.