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.
From: Justin Uberti
[mailto:juberti@google.com] Sent: den 21 januari 2011
09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry
Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen
Botzko Subject: Re: [RTW] Rate control and codec adaption (Re:
[dispatch] The charter formerly know as RTC-WEB take 3)
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.
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).
From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: den 21 januari 2011 08:46 To: Henry
Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen
Jennings; rtc-web@alvestrand.no; DISPATCH list Subject:
Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly
know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
>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.
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. Can
you explain?
Changing the subject to content
of thread....
are we reducing to a previously solved problem, or to
a previously unsolved problem? 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).
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, Stefan
From:
Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent:
den 20 januari 2011 16:45 To: Henry
Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings;
DISPATCH list; rtc-web@alvestrand.no Subject: Re:
[dispatch] The charter formerly know as RTC-WEB take
3
>>> How
does this fit with adaptive codecs? >>> 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.
>>> Hint:
codec selection matters, is actually critical to this
effort. >>> 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.
> 2. The second one is about
rate adaptation/congestion control. It is not >
mentioned at all. I don't know if it is needed, perhaps it
is enough that > RFC3550 (that is already pointed at) has a
section about it, but I wanted to > highlight
it.
How does this fit with adaptive codecs? Hint:
codec selection matters, is actually critical to this
effort.
>
Hi Cullen, > > two comments: > > 1.
As requirements on the API are explicitly described, I
thinke that there > should be a comment that the API must
support media format negotiation. > Proposal: "The API
must enable media format negotiation and application >
influence over media format selection". > > 2.
The second one is about rate adaptation/congestion control.
It is not > mentioned at all. I don't know if it is
needed, perhaps it is enough that > RFC3550 (that is
already pointed at) has a section about it, but I wanted
to > highlight it. > > Br, >
Stefan > >> -----Original
Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On
Behalf Of Cullen Jennings >> Sent: den 18 januari
2011 05:59 >> To: DISPATCH list >> Cc: rtc-web@alvestrand.no >> Subject:
[dispatch] The charter formerly know as RTC-WEB take
3 >> >> >> In my dispatch
co-chair role, I tried to take all the >> comments
I had seen on the list about this charter and see
if >> I could address them in a new version of the
charter. I >> probably messed up in some places.
There were some >> conversation that did not seem
to be converging so I did not >> make any changes
for theses. Have a read and if you think >>
something needs to be changed, propose text changes
along >> with the reasons why and we will keep the
evolving this charter. >> >>
Thanks >> Cullen >> >>
-------------------------------------------------------------- >>
-------------------- >> >> Version:
3 >> >> Possible
Names: >> >> RTCWEB >>
WEBRTC >> STORM: Standardized Transport Oriented
for Realtime Media >> BURN: Browsers Using Realtime
Media >> WAVE: Web And Voice/Video
Enablement >> WAVVE: Web And Voice Video
Enablement >> REALTIME >>
WEBCOMM >> WREALTIME >>
WEBTIME >> WEBFLOWS >> BRAVO Browser
Realtime Audio and VideO >> COBWEB COmmuication
Between WEBclients >>
WHEELTIME >> >> >> >>
Body: >> >> Many implementations have been
made that use a Web browser to >> support direct,
interactive communications, including voice, >>
video, collaboration, and gaming. In these
implementations, >> the web server acts as the signaling
path between these >> applications, using locally
significant identifiers to set up >> the
association. Up till now, such applications
have >> typically required the installation of plugins
or >> non-standard browser extensions. There
is a desire to >> standardize this functionality,
so that this type of >> application can be run in
any compatible browser and allow >> for
high-quality real-time communications experiences
within >> the browser. >> >>
Traditionally, the W3C has defined API and markup
languages >> such as HTML that work in conjunction
with with the IETF over >> the wire protocols such
as HTTP to allow web browsers to >> display media
that does not have real time interactive >>
constraints with another human. >> >> The
W3C and IETF plan to collaborate together in
their >> traditional way to meet the evolving needs of
browsers. >> Specifically the IETF will provide a
set of on the wire >> protocols, including RTP, to
meet the needs on interactive >> communications,
and the W3C will define the API and markup to >>
allow web application developers to control the on the
wire >> protocols. This will allow application
developers to write >> applications that run in a
browser and facilitate interactive >>
communications between users for voice and video >>
communications, collaboration, and
gaming. >> >> This working group will
select and define a minimal set of >> protocols
that will enable browsers to: >> >> * have
interactive real time voice and video pairwise
be