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

[Stephen Botzko]

>>>
   How does this fit with adaptive codecs?
>>>
Just because some codecs can adapt doesn't mean rate adaptation/congestion
control should be left out of the scope.  I think it needs to be considered.

>>>
   Hint: codec selection matters, is actually critical to this effort.
>>>
Codec selection does matter, but I am not convinced that mandatory codecs
need to be in the RFCs.  I believe market forces are sufficient - SIP itself
is one proof point.

Stephen Botzko


On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich at gmail.com
> wrote:

> Hi Stefan,
>
> > 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.
>
> How does this fit with adaptive codecs?
> Hint: codec selection matters, is actually critical to this effort.
>
> Thanks, Henry
>
>
> On 1/20/11 3: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".
> >
> > 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
> >>
> > _______________________________________________
> > dispatch mailing list
> > dispatch at ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110120/0da66acc/attachment-0001.html>