so: I’m trying to implement a mulitparty call with Licode.
everything works ok if left untouched (es. default adapt scheme: notify).
This means that if a user with poor connection join, the publisher will adapt to his connection.
We now want to set a minimum bw. ex: 1000 kbit/s and set the publisher to use notify-break-recover for example.
2 user connected with no bw problem, publishing and subscribing at max allowed bw (ex. 3000 kbit/s);
we now join the call with a third user, connected to another router which is set to limit download bandwidth @ 600kbit/s
what we expect:
the publisher will temporarily adjust its throughput @ 600 kbit/s, the scheme will notice that the bw of “evil” subscriber is insufficient and try to recover it. it cannot recover then it stops and sets him in audio only mode.
the publisher can now re-adapt its bw to the second participant @ 3000 kbit/s as before.
what we got:
the publisher will temporarily adjust its throughput @ 600 kbit/s, the scheme will notice that the bw of “evil” subscriber is insufficient and set him in newState: BW_INSUFFICIENT;
BUT: also the second user, which has no bw problem, is set to BW_INSUFFICIENT. this will prevent rembs of all the 2 subscriber to be forwarded to publisher, which will remain < 1000 kbit cause no one send rembs to him, and the 2 subscriber will never recover.
the recover mechanism is based on availableRecvBW, which is computed by chrome based on the AvailablesendBw of the publisher. this cause a loop, where no one can recover.
We have now a bandwithEstimation module which generates rembs, so, when every participant is set to recover, we could pass to the publisher our genuine rembs generated from server, so the publisher will recover its availablesendBW value and also our subscribers (only those who have enough bandwidth) can recover.
Are my thoughts corrects? Can you reproduce the issue?
I think it’s a very delicate question which can play a main role in terms of qos and user experience.
PS. Happy New Year Licode Community!