<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6001.18542" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=552263508-21012011><FONT face=Arial
color=#0000ff size=2>Isn't it so that with the AVPF profile you can actually
sent RTCP when there is a need (even if a transmission is not due)? This way you
can actually react fast. </FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
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> Justin Uberti
[mailto:juberti@google.com] <BR><B>Sent:</B> den 21 januari 2011
09:13<BR><B>To:</B> Stefan Håkansson LK<BR><B>Cc:</B> Harald Alvestrand; Henry
Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen
Botzko<BR><B>Subject:</B> Re: [RTW] Rate control and codec adaption (Re:
[dispatch] The charter formerly know as RTC-WEB take 3)<BR></FONT><BR></DIV>
<DIV></DIV>RTCP typically isn't sent frequently enough to allow for real-time
adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate
in real-time, but the work to apply TFRC to RTP has not yet been codified into
a standard.
<DIV><BR></DIV>
<DIV>There was a draft but it has been abandonded (<A
href="http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10">http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10</A>)<BR><BR>
<DIV class=gmail_quote>On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK
<SPAN dir=ltr><<A
href="mailto:stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV bgcolor="#ffffff" text="#000000">
<DIV dir=ltr align=left><SPAN><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 lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> Harald Alvestrand [mailto:<A
href="mailto:harald@alvestrand.no" target=_blank>harald@alvestrand.no</A>]
<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; <A href="mailto:rtc-web@alvestrand.no"
target=_blank>rtc-web@alvestrand.no</A>; 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></DIV>
<DIV class=h5>
<DIV></DIV>On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
<BLOCKQUOTE 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 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="http://stefan.lk.hakansson@ericsson.com"
target=_blank>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"
target=_blank>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="http://rtc-web@alvestrand.no"
target=_blank>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="http://henry.sinnreich@gmail.com"
target=_blank>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="http://stefan.lk.hakansson@ericsson.com"
target=_blank>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="http://dispatch-bounces@ietf.org"
target=_blank>dispatch-bounces@ietf.org</A><BR>>> [<A
href="mailto:dispatch-bounces@ietf.org"
target=_blank>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="http://rtc-web@alvestrand.no"
target=_blank>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><FIELDSET></FIELDSET>
_______________________________________________
RTC-Web mailing list
<A href="mailto:RTC-Web@alvestrand.no" target=_blank>RTC-Web@alvestrand.no</A>
<A href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A>
</PRE></BLOCKQUOTE><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>RTC-Web
mailing list<BR><A
href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</A><BR><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>