<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
<blockquote cite="mid:C95E1C08.1838B%25henry.sinnreich@gmail.com"
type="cite">
<title>Re: [dispatch] The charter formerly know as RTC-WEB take 3</title>
<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>
</font></span></blockquote>
Changing the subject to content of thread....<br>
<br>
are we reducing to a previously solved problem, or to a previously
unsolved problem?<br>
I don't see how this problem actually differs from the one that
people will have when operating RTP under TFRC
(draft-ietf-avt-tfrc-profile-10).<br>
<br>
<blockquote cite="mid:C95E1C08.1838B%25henry.sinnreich@gmail.com"
type="cite"><span style="font-size: 13pt;"><font face="Calibri,
Verdana, Helvetica, Arial">
<br>
Thanks, Henry<br>
<br>
<br>
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <<a
moz-do-not-send="true"
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 size="3" width="100%" align="CENTER"> </font><font
face="Tahoma, Verdana, Helvetica, Arial"><b>From:</b>
Stephen Botzko [<a moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a><br>
>> [<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
RTC-Web mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a>
<a class="moz-txt-link-freetext" href="http://www.alvestrand.no/mailman/listinfo/rtc-web">http://www.alvestrand.no/mailman/listinfo/rtc-web</a>
</pre>
</blockquote>
<br>
</body>
</html>