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

[Peter Musgrave]

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