[RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)

[Matthew Kaufman]

Agreed, but for the purpose of this discussion I believe that rate 
control of some sort should also be a MUST.

Web browsers are extremely prevalent, and we hope that RTC use in 
browsers will be high, and so it would be good for the Internet for 
browsers to have sending rate control. Note that this is at the protocol 
level... so send rate must be controlled whether the codec can have its 
rate adjusted downward so as to not require the protocol level to 
enforce or not.

For interoperability, it is also required that the feedback mechanism 
from one end to the other be standardized, even if the way that feedback 
is used to control send rate and/or codec selection or codec rate 
selection is proprietary and/or extensions to the feedback are also sent 
for endpoints that understand the (possibly proprietary) extension(s).

Matthew Kaufman

On 1/25/2011 7:38 AM, Rosenberg, Jonathan wrote:
>
> It’s a proprietary algorithm of our own design, supported by some 
> protocols which exchange feedback in real-time between endpoints. 
> We’re constantly tweaking it based on user feedback and technical 
> statistics we collect.
>
> Indeed – as many folks are aware, rate adaptation has always been an 
> area of innovation and differentiation. RTP has provided the tools for 
> feedback but has allowed implementations to do whatever they want. I 
> think it is important that this continues to be the case in the web 
> world – that folks designing RTC applications can innovate and define 
> their own versions of these algorithms.
>
> Thanks,
>
> Jonathan R.
>
> Jonathan D. Rosenberg, Ph.D.               SkypeID: jdrosen
>
> Chief Technology Strategist                Mobile: +1 (732) 766-2496
>
> Skype                                      SkypeIn: +1 (408) 465-0361
>
> jdrosen at skype.net                          http://www.skype.com
>
> jdrosen at jdrosen.net                        http://www.jdrosen.net
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110125/c653290a/attachment.html>