[RTW] WG charter, take 4
Bernard Aboba
bernard_aboba at hotmail.com
Fri Feb 25 15:33:00 CET 2011
+1
-----Original Message-----
From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
On Behalf Of Elwell, John
Sent: Friday, February 25, 2011 12:00 AM
To: Rosenberg, Jonathan; 'Harald Alvestrand'; RTC-Web at alvestrand.no
Subject: Re: [RTW] WG charter, take 4
+1
John
> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of
> Rosenberg, Jonathan
> Sent: 24 February 2011 16:33
> To: 'Harald Alvestrand'; RTC-Web at alvestrand.no
> Subject: Re: [RTW] WG charter, take 4
>
> A few comments:
>
> I'm happy with the charter language around discussion of session
> management protocols being in scope for the WG. I don't
> understand why,
> during the BoF, we will discuss whether to bake a decision on
> this into
> the charter. Determining the protocols needed for browser RTC
> - both the
> types of protocols and specific protocol instances and
> profiles - is the
> work of the group and NOT the work of the charter.
>
> This piece of wording is also concerning:
> >have interactive real time voice and video pairwise between
> browsers or
> >other devices using RTP
>
> While I think we agree this is a goal, there are real
> security issues in
> play here that the group needs to iron out. I do not want to bake in a
> charter requirement that says we MUST deliver a solution that allows
> point-to-point media (i.e., no gateways or SBCs or other
> intermediaries)
> between browsers and existing RTP endpoints. I'd suggest
> something softer
> like:
>
> "enable real-time voice and video communications between browsers and
> non-browser endpoints, with direct media when possible based
> on security
> and interoperability considerations"
>
> Which states the intent but leaves the recommendation to the wg.
>
> Thanks,
> Jonathan R.
>
>
> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen
> Skype Chief Technology Strategist
> jdrosen at skype.net http://www.skype.com
> jdrosen at jdrosen.net http://www.jdrosen.net
>
>
> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no
> [mailto:rtc-web-bounces at alvestrand.no]
> On Behalf Of Harald Alvestrand
> Sent: Thursday, February 24, 2011 8:45 AM
> To: RTC-Web at alvestrand.no
> Subject: [RTW] WG charter, take 4
>
> This is the current charter text - it's updated somewhat based on
> discussions on the list.
>
> In particular, there's now suggested language about the
> relationship to
> session management protocols.
> We'll make this an explicit discussion at the BOF, with the aim of
> getting one of three conclusions in the charter:
>
> - The WG will not address session management protocols
> - The WG will choose one or more session management protocols
> - The WG will discuss session management protocols, and do what makes
> sense.
>
> The last one is the one suggested by the current charter
> text; the other
> possible outcomes should be easier to write text for.
>
> Comments welcome!
>
> Harald
>
> (Note: The below is not going out in < 80 columns, I think. Please
> forgive the formatting issue.)
>
> ------------------------------------------------
>
> Version: 4
>
> Name: RTCWEB
> WG Chair(s): Cullen Jennings <fluffy at cisco.com>
>
> 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 described 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.
>
> This group's primary aim is to enable web applications to manage
> real-time communication sessions with other web-context applications
> that implement this specification. When making choices, the working
> group will also consider the impact of those choices on
> interoperability
> with other devices that create or manage multimedia sessions,
> including
> the complexity imposed
> on any gateways which may be required.
>
> The Working group will identify information needed for session
> negotiation and management in web contexts, and its output documents
> will describe the relationship of this to information carried
> in session
> protocols used in other standardized contexts.
>
> The Working Group will consider the possibility of defining a browser
> component that implements an existing session negotiation and
> management
> protocol.
>
> 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 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, and if
> there are parts of the mapping between the API and the protocols that
> need to be done outside of the W3C, this group will do it.
>
> 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.
>
> Deliverables:
> An overview document describing the architecture
> A scenarios document describing scenarios that are expected to be
> supported
> A profile document specifying the protocols and options that must be
> supported by a conforming implementation
> (If needed) A mapping document describing the relationship between the
> protocols and the W3C-defined API.
>
>
> 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 Draft available of 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 document submitted to the IESG as Informational (if
> needed)
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web
More information about the RTC-Web
mailing list