Re: setting bandwidth

Dear Goran Eriksson/Piranna,

Yes, It can be done by application too.
But maintaining such timer in the lower level, might be more appropriate.
It will reduce unnecessary call backs.
(Even though this is may not be the perfect example, some signaling
protocols like SIP are maintaining their timers in the lower layers instead
of application layer).

Thanks,
Kiran.



On Wed, Jul 24, 2013 at 6:47 PM, Göran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>
>
> 24 jul 2013 kl. 15:04 skrev "Kiran Kumar" <g.kiranreddy4u@gmail.com>:
>
>   This seems to be nice Idea to send callbacks.
> But I suggest to add some timer on top of it. Like If the bandwidth drops
> below a certain minimum level, then it should wait for a predefined window
> time, if the bandwidth is still less than the minimum limit, then only it
> should send a call back.
> Because there are many network scenarios, that affects the bandwidth for a
> minute period of time, and recover to its normal state soon.
>
>
>  That is an option but is that not up to the application to have a timer,
> a counter or what ever is needed to decide on an action?
>
>
>
>
>
>
>  Thanks,
> Kiran.
>
>
>
> On Wed, Jul 24, 2013 at 11:16 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>>  On 24/07/2013 12:26 AM, Cullen Jennings (fluffy) wrote:
>>
>>> On Jul 18, 2013, at 6:21 AM, Stefan Håkansson LK <
>>> stefan.lk.hakansson@ericsson.**com <stefan.lk.hakansson@ericsson.com>>
>>> wrote:
>>>
>>>  2. Setting BW for a MediaStreamTrack
>>>> ------------------------------**------
>>>> Why: There are situations where a suitable start bit-rate can be known,
>>>> or guessed. If this knowledge could be used the perceived end-user
>>>> quality could be improved (since a higher quality is available from
>>>> start since there is no need to start at a really low bit-rate).
>>>>
>>>> There are also situations where it could be beneficial if min and max
>>>> bit-rates to be used can be influenced.
>>>>
>>>> * The app developer may know that below a certain bit-rate the quality
>>>> is so bad that the browser could stop sending it, and likewise there may
>>>> be knowledge about a bit-rate above which the quality does not improve.
>>>>
>>>> * There are situations when there is an agreement between the service
>>>> provider and the connectivity provider about min and max bit-rates.
>>>>
>>>> What: Again, this depends on how much BW info is included in the SDP.
>>>> But my understanding is that there should be some (since RTCP rates to
>>>> be used are based on this info IIUC).
>>>>
>>> I agree and think we need to a couple things here. One is setting the
>>> limits for the bandwidth but the  other is using the stats interface to
>>> read the current bandwidth being used.
>>>
>>
>>      A slightly related but higher-level proposal: replace Mandatory
>> constraints with Optional constraints that act as Fence conditions.
>>
>>     It works like this: You specify a bunch of optional constraints and a
>> callback to be invoked when a Constraint is violated. For example, I would
>> ask for a bandwidth between 1Mbit and 2Mbit. If bandwidth drops below the
>> minimum, the callback gets invoked. I then reduce the video resolution, or
>> turn off audio, or... whatever the application wants... and set new min/max
>> bandwidth bounds. If the maximum bound is surpassed, I know I can afford to
>> increase the video resolution so I do so. And so on.
>>
>>     Assuming I'm wrong (you need mandatory constraints) I still think
>> adding this fence behavior puts control in the right place. The application
>> is uniquely positioned to decide what happens when the connection
>> capabilities change.
>>
>> Gili
>>
>>
>