[RTW] [dispatch] The charter formerly know as RTC-WEB take 3

[Henry Sinnreich]

>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>