[RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Stefan Håkansson LK
stefan.lk.hakansson at ericsson.com
Thu Jan 20 10:52:32 CET 2011
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
>
More information about the RTC-Web
mailing list