[RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Peter Musgrave
peter.musgrave at magorcorp.com
Tue Jan 18 14:43:46 CET 2011
Hi Cullen,
Thanks for the summary.
I think this is useful work that RAI should take on.
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
Regards,
Peter Musgrave
On 2011-01-17, at 11:58 PM, Cullen Jennings wrote:
>
> 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