Re: setting bandwidth

On 25 July 2013 21:24, Kiran Kumar <g.kiranreddy4u@gmail.com> wrote:
> The timer implementation I suggested, is to avoid the error condition that
> can arise as a result of Gili's proposal callback API.

Unfortunately, having a specific timer-based constraint will cause
problems.  Different browsers are likely to implement very different
rate control mechanisms, as we have already seen with the video
comparison tests (in RTCWEB).  The time periods over which bandwidth
is controlled and how rate control is implemented are intimately tied.
 What this sort of mechanism is likely to do is force applications to
learn about the intricate detail of each browser (probably using user
agent sniffing techniques) in order to control the bandwidth consumed.

In some respects, Cullen's proposal is elegant, but I think that we
really need a mechanism that effectively just sets the b= line in SDP.
 Note that this doesn't necessary have to be negotiated as long as the
number that is set is lower than the negotiated value.  However, for
consistency purposes, I'd probably just make this a constraint on
createOffer and maybe createAnswer, which would force the use of
setLocalDescription etc...

Also, to anyone considering a minimum value for a bandwidth
constraint.  There is no way that this would ever be a good idea.  The
browser will have to respect the congestion signals it receives and
reduce bandwidth accordingly.  Allowing an application to force a
minimum rate would allow bad actors to generate congestion on the
Internet.  Besides, good codecs encode still images and silence at
near zero rates during normal operation, we wouldn't want to prevent
that.  Minimum target quality levels are something else, of course.

Received on Saturday, 27 July 2013 15:59:15 UTC