<HTML>
<HEAD>
<TITLE>Re: [dispatch] The charter formerly know as RTC-WEB take 3</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>></SPAN></FONT><SPAN STYLE='font-size:13pt'><FONT COLOR="#0000FE"><FONT FACE="Arial">Minor comment: I think all codecs that have been discussed (except for G.711) are adaptive in the sense that their bitrate can be adapted.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers.<BR>
Can you explain?<BR>
<BR>
Thanks, Henry<BR>
<BR>
<BR>
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <<a href="stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</a>> wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:13pt'><FONT COLOR="#0000FF"><FONT FACE="Arial">Minor comment: I think all codecs that have been discussed (except for G.711) are adaptive in the sense that their bitrate can be adapted.<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial">Br,<BR>
Stefan<BR>
</FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:13pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial"> <BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="100%"> </FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Stephen Botzko [<a href="mailto:stephen.botzko@gmail.com">mailto:stephen.botzko@gmail.com</a>] <BR>
<B>Sent:</B> den 20 januari 2011 16:45<BR>
<B>To:</B> Henry Sinnreich<BR>
<B>Cc:</B> Stefan Håkansson LK; Cullen Jennings; DISPATCH list; <a href="rtc-web@alvestrand.no">rtc-web@alvestrand.no</a><BR>
<B>Subject:</B> Re: [dispatch] The charter formerly know as RTC-WEB take 3<BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
<BR>
>>><BR>
How does this fit with adaptive codecs?<BR>
>>><BR>
Just because some codecs can adapt doesn't mean rate adaptation/congestion control should be left out of the scope. I think it needs to be considered.<BR>
<BR>
>>><BR>
Hint: codec selection matters, is actually critical to this effort.<BR>
>>><BR>
Codec selection does matter, but I am not convinced that mandatory codecs need to be in the RFCs. I believe market forces are sufficient - SIP itself is one proof point.<BR>
<BR>
Stephen Botzko<BR>
<BR>
<BR>
<BR>
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <<a href="henry.sinnreich@gmail.com">henry.sinnreich@gmail.com</a>> wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE='font-size:13pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial">Hi Stefan,<BR>
<BR>
<BR>
> 2. The second one is about rate adaptation/congestion control. It is not<BR>
> mentioned at all. I don't know if it is needed, perhaps it is enough that<BR>
> RFC3550 (that is already pointed at) has a section about it, but I wanted to<BR>
> highlight it.<BR>
<BR>
How does this fit with adaptive codecs?<BR>
Hint: codec selection matters, is actually critical to this effort.<BR>
<BR>
Thanks, Henry<BR>
<BR>
<BR>
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <<a href="stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</a>><BR>
wrote:<BR>
<BR>
<BR>
<BR>
<BR>
> Hi Cullen,<BR>
><BR>
> two comments:<BR>
><BR>
> 1. As requirements on the API are explicitly described, I thinke that there<BR>
> should be a comment that the API must support media format negotiation.<BR>
> Proposal: "The API must enable media format negotiation and application<BR>
> influence over media format selection".<BR>
><BR>
> 2. The second one is about rate adaptation/congestion control. It is not<BR>
> mentioned at all. I don't know if it is needed, perhaps it is enough that<BR>
> RFC3550 (that is already pointed at) has a section about it, but I wanted to<BR>
> highlight it.<BR>
><BR>
> Br,<BR>
> Stefan<BR>
><BR>
>> -----Original Message-----<BR>
>> From: <a href="dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a><BR>
>> [<a href="mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.org</a>] On Behalf Of Cullen Jennings<BR>
>> Sent: den 18 januari 2011 05:59<BR>
>> To: DISPATCH list<BR>
>> Cc: <a href="rtc-web@alvestrand.no">rtc-web@alvestrand.no</a><BR>
>> Subject: [dispatch] The charter formerly know as RTC-WEB take 3<BR>
>><BR>
>><BR>
>> In my dispatch co-chair role, I tried to take all the<BR>
>> comments I had seen on the list about this charter and see if<BR>
>> I could address them in a new version of the charter. I<BR>
>> probably messed up in some places. There were some<BR>
>> conversation that did not seem to be converging so I did not<BR>
>> make any changes for theses. Have a read and if you think<BR>
>> something needs to be changed, propose text changes along<BR>
>> with the reasons why and we will keep the evolving this charter.<BR>
>><BR>
>> Thanks<BR>
>> Cullen<BR>
>><BR>
>> --------------------------------------------------------------<BR>
>> --------------------<BR>
>><BR>
>> Version: 3<BR>
>><BR>
>> Possible Names:<BR>
>><BR>
>> RTCWEB<BR>
>> WEBRTC<BR>
>> STORM: Standardized Transport Oriented for Realtime Media<BR>
>> BURN: Browsers Using Realtime Media<BR>
>> WAVE: Web And Voice/Video Enablement<BR>
>> WAVVE: Web And Voice Video Enablement<BR>
>> REALTIME<BR>
>> WEBCOMM<BR>
>> WREALTIME<BR>
>> WEBTIME<BR>
>> WEBFLOWS<BR>
>> BRAVO Browser Realtime Audio and VideO<BR>
>> COBWEB COmmuication Between WEBclients<BR>
>> WHEELTIME<BR>
>><BR>
>><BR>
>><BR>
>> Body:<BR>
>><BR>
>> Many implementations have been made that use a Web browser to<BR>
>> support direct, interactive communications, including voice,<BR>
>> video, collaboration, and gaming. In these implementations,<BR>
>> the web server acts as the signaling path between these<BR>
>> applications, using locally significant identifiers to set up<BR>
>> the association. Up till now, such applications have<BR>
>> typically required the installation of plugins or<BR>
>> non-standard browser extensions. There is a desire to<BR>
>> standardize this functionality, so that this type of<BR>
>> application can be run in any compatible browser and allow<BR>
>> for high-quality real-time communications experiences within<BR>
>> the browser.<BR>
>><BR>
>> Traditionally, the W3C has defined API and markup languages<BR>
>> such as HTML that work in conjunction with with the IETF over<BR>
>> the wire protocols such as HTTP to allow web browsers to<BR>
>> display media that does not have real time interactive<BR>
>> constraints with another human.<BR>
>><BR>
>> The W3C and IETF plan to collaborate together in their<BR>
>> traditional way to meet the evolving needs of browsers.<BR>
>> Specifically the IETF will provide a set of on the wire<BR>
>> protocols, including RTP, to meet the needs on interactive<BR>
>> communications, and the W3C will define the API and markup to<BR>
>> allow web application developers to control the on the wire<BR>
>> protocols. This will allow application developers to write<BR>
>> applications that run in a browser and facilitate interactive<BR>
>> communications between users for voice and video<BR>
>> communications, collaboration, and gaming.<BR>
>><BR>
>> This working group will select and define a minimal set of<BR>
>> protocols that will enable browsers to:<BR>
>><BR>
>> * have interactive real time voice and video pairwise be<BR>
</FONT></SPAN></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>