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

[Stefan Håkansson LK]

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
>