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

Thu Jan 20 20:59:37 CET 2011

Hi!

Honestly I don't know what CONNEG is. I was after 
1. One API where the application (implemented in JS) can query what media formats that are supported
2. The possibility to define the media format to be used when setting up a stream (via an API)

With the info acquired with 1. the capabilties of the two peers can be exchanged, and formats can be negotiated. Exactly how this is done is probably out of scope of RTC-Web, at least initially (but maybe there could be some kind of industry standard on how to do this to make interop easier).

Note that it is not only to select codec when you set up the stream. You would need to define e.g. framerate, resolution, bitrate, ...

I also think that it would be an advantage if the format of the data acquired in 1. is easy to translate to an SDP as described in Section 6 of http://datatracker.ietf.org/doc/draft-alvestrand-dispatch-rtcweb-protocols/?include_text=1

Br,
Stefan

> -----Original Message-----
> From: Ted Hardie [mailto:ted.ietf at gmail.com] 
> Sent: den 20 januari 2011 17:58
> To: Stefan Håkansson LK
> Cc: Cullen Jennings; DISPATCH list; rtc-web at alvestrand.no
> Subject: Re: [RTW] [dispatch] The charter formerly know as 
> RTC-WEB take 3
> 
> Howdy,
> 
> On Thu, Jan 20, 2011 at 1: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".
> >
> 
> Are you thinking that the API should allow for something like 
> SIP's use of the CONNEG framework (that is, allow the overall 
> system to use a set intersection model, with the API acting on the set
> membership?)
> 
> regards,
> 
> Ted Hardie
> 
> 
> > 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
> >>
> > _______________________________________________
> > RTC-Web mailing list
> > RTC-Web at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
> 