[RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Henry Sinnreich
henry.sinnreich at gmail.com
Fri Jan 21 00:06:16 CET 2011
>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?
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson at 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 at gmail.com]
>> Sent: den 20 januari 2011 16:45
>> To: Henry Sinnreich
>> Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list;
>> rtc-web at 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 at 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 at 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 at ietf.org
>>>>> >> [mailto:dispatch-bounces at ietf.org] On Behalf Of Cullen Jennings
>>>>> >> Sent: den 18 januari 2011 05:59
>>>>> >> To: DISPATCH list
>>>>> >> Cc: rtc-web at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110120/193d2a0a/attachment.html>
More information about the RTC-Web
mailing list