>>><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><div class="gmail_quote">On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <span dir="ltr"><<a href="mailto:henry.sinnreich@gmail.com">henry.sinnreich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Stefan,<br>
<div class="im"><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>
</div>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="mailto:stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</a>><br>
wrote:<br>
<div><div></div><div class="h5"><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="mailto:dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a><br>
>> [mailto:<a href="mailto:dispatch-bounces@ietf.org">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="mailto:rtc-web@alvestrand.no">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 between browsers<br>
>>   or other devices using RTP<br>
>><br>
>> * have interactive real time application data for collaboration and<br>
>>   gaming pairwise between browsers<br>
>><br>
>> Fortunately very little development of new protocol at IETF<br>
>> is required for this, only selection of existing protocols<br>
>> and selection of minimum capabilities to ensure<br>
>> interoperability. The following protocols are candidates for<br>
>> including in the profile set:<br>
>><br>
>> 1) RTP/ RTCP<br>
>><br>
>> 2) a baseline audio codec for high quality interactive audio.<br>
>> Opus will<br>
>>    be one of the codecs considered<br>
>><br>
>> 3) a baseline audio codec for PSTN interoperability. G.711<br>
>> and iLBC will<br>
>>    be some of the codecs considered<br>
>><br>
>> 4) a baseline video codec. H.264 and VP8 will be some of the codecs<br>
>>    considered<br>
>><br>
>> 5) Diffserv based QoS<br>
>><br>
>> 6) NAT traversal using ICE<br>
>><br>
>> 7) media based DTMF<br>
>><br>
>> 8) support for identifying streams purpose using semantics labels<br>
>>    mappable to the labels in RFC 4574<br>
>><br>
>> 9) Secure RTP and keying<br>
>><br>
>> 10) support for IPv4, IPv6 and dual stack browsers<br>
>><br>
>> Please note the above list is only a set of candidates that<br>
>> the WG may consider and is not list of things that will be in<br>
>> the profile the set.<br>
>><br>
>> The working group will cooperate closely with the W3C<br>
>> activity that specifies a semantic level API that allows the<br>
>> control and manipulation of all the functionality above. In<br>
>> addition, the API needs to communicate state information and<br>
>> events about what is happening in the browser that to<br>
>> applications running in the browser. These events and state<br>
>> need to include information such as: receiving DTMF in the<br>
>> RTP, RTP and RTCP statistics, and the state of DTLS/SRTP<br>
>> handshakes. The output of this WG will form input to the W3C<br>
>> group that specifies the API.<br>
>><br>
>> The working group will follow BCP 79, and adhere to the<br>
>> spirit of BCP 79. The working group cannot explicitly rule<br>
>> out the possibility of adopting encumbered technologies;<br>
>> however, the working group will try to avoid encumbered<br>
>> technologies that require royalties or other encumbrances<br>
>> that would prevent such technologies from being easy to use<br>
>> in web browsers.<br>
>><br>
>> The following topics will be out of scope for the initial<br>
>> phase of the WG but could be added after a recharter: RTSP,<br>
>> RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource<br>
>> Priority. RTP Payload formats will not be done in this WG.<br>
>><br>
>> Milestones:<br>
>><br>
>> May 2011 Main alternatives identified in drafts<br>
>><br>
>> Aug 2011 WG draft with text reflecting agreement of what the<br>
>> profile set<br>
>>          should be<br>
>><br>
>> Sept 2011 Scenarios specification to IESG as Informational<br>
>><br>
>> Nov 2011 Documentation specifying mapping of protocol functionality to<br>
>>          W3C-specified API produced. This is an input to W3C API work.<br>
>><br>
>> Dec 2011 Profile specification to IESG as PS<br>
>><br>
>> Apr 2012 Mapping W3C defied API to IETF protocols to IESG as<br>
>>          Informational. This depends on the W3C API work.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> dispatch mailing list<br>
>> <a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
>> <a href="https://www.ietf.org/mailman/listinfo/dispatch" target="_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
>><br>
> _______________________________________________<br>
> dispatch mailing list<br>
> <a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/dispatch" target="_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
<br>
<br>
_______________________________________________<br>
dispatch mailing list<br>
<a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/dispatch" target="_blank">https://www.ietf.org/mailman/listinfo/dispatch</a><br>
</div></div></blockquote></div><br>