<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [dispatch] The charter formerly know as RTC-WEB take 3</TITLE>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1">
<META content="MSHTML 6.00.6001.18542" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=431314707-21012011><FONT face=Arial
color=#0000ff size=2>My view: we are discussing a problem already solved! The
common procedure would be to use info in the RTCP reports from the receiving end
to change the transmitted bit rate (if change is required).
</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Harald Alvestrand
[mailto:harald@alvestrand.no] <BR><B>Sent:</B> den 21 januari 2011
08:46<BR><B>To:</B> Henry Sinnreich<BR><B>Cc:</B> Stefan Håkansson LK; Stephen
Botzko; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH
list<BR><B>Subject:</B> Rate control and codec adaption (Re: [RTW] [dispatch]
The charter formerly know as RTC-WEB take 3)<BR></FONT><BR></DIV>
<DIV></DIV>On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
<BLOCKQUOTE cite=mid:C95E1C08.1838B%25henry.sinnreich@gmail.com
type="cite"><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
href="stefan.lk.hakansson@ericsson.com"
moz-do-not-send="true">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 width="100%" SIZE=3>
</FONT><FONT face="Tahoma, Verdana, Helvetica, Arial"><B>From:</B>
Stephen Botzko [<A href="mailto:stephen.botzko@gmail.com"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">dispatch-bounces@ietf.org</A><BR>>>
[<A href="mailto:dispatch-bounces@ietf.org"
moz-do-not-send="true">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"
moz-do-not-send="true">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></BLOCKQUOTE></BODY></HTML>