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

[Henry Sinnreich]

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