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).
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).
Thanks,
Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com>
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.
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.
Stephen Botzko
On Thu,
Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com>
wrote:
Hi
Stefan,
> 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.
Thanks,
Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK"
<stefan.lk.hakansson@ericsson.com>
wrote:
>
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
_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web