Re: Scoping WebRTC 1.0

+1.

On Jul 7, 2015, at 11:26 AM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

I'm supportive of the proposed process of, basically, "have a PR by September if you want it in 1.0".  I like how it's is a clear definition of what we need to look at in September, and gives us all impetus to get things done by a certain time.

By the way, I plan on getting out PRs for the following soon, certainly before September:

RtpSender/RtpReceiever.getCapabilities (had good consensus at TPAC 2014)

RtpEncodingParameters.maxBitrate (not as clear consensus, but lots of people mentioned the need at TPAC 2014)

RtpSenderInit (has rough consensus on the list)

SctpTransport (had rough consensus at TPAC 2014, and on the list in Nov 2014)

On Mon, Jun 29, 2015 at 11:31 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>> wrote:
Sorry for a rather long mail. It is about the scoping of WebRTC 1.0, and
the mail has three parts, "background", "proposed process" and
"features". We are especially eager to get feedback on the proposed
process *by July 10*, so if you're going to read only one part read that
one.

Background
==========
We think it is time to revisit the WebRTC 1.0 scope again. We made an
attempt late 2013, and at that time used the spreadsheet in [1] as basis
for the discussion.

We were not hugely successful at the time, but we think things are
different now. For one, many of the features discussed at that time are
now part of the spec (or in PR's being actively discussed). Secondly,
the new Charter we will (hopefully) operate under soon [2] list "WebRTC
next version" as something that will get to FPWD Q1 2016 - this means
there is a clear place for the features we determine be beyond 1.0 to
go. And thirdly, the charter also says that WebRTC 1.0 should reach CR
in Q4 this year, meaning we should get serious on what is in and out of
it soon.

Proposed process
================
We think that we should use the upcoming face-to-face meeting in
September to determine what is in 1.0. And in order to be "in" we will
require that the group (at the meeting) has consensus for the feature,
and that a relatively baked PR exists.

This means that proponents of features must use the time up to the f2f
to create and refine PRs, push for discussion on the list, and that the
group must help by providing feedback.

Is this a process we can follow? *Please provide feedback by July 10!*
Silence will be interpreted as being OK with this process.

Features
========
Looking at the old 2013 spreadsheet in combination with github Issues
and PRs, it to us looks something like (note, this is not an official
position in any way, it is just an attempt to sort features based on our
understanding of where we are currently):

Features from 2013 labeled "Not in 1.0" that are now in the spec
----------------------------------------------------------------
*RtpSenders/Receivers
*Rollback in state machine
*Track rejection (though we have the detail of making sure the rejected
track is not part of future offers)
*Bundle tuning
*Call hold
*Certificate handling APIs
*Identity

Features we seem to have consensus to add, need to sort details
----------------------------------------------------------------
*replaceTrack
*unassigned media handling (PR #29 goes a bit)

Features where we have PRs/active discussion, but not clear consensus to add
---------------------------------------------------------------------
*ICE object
*DTLS  object
*codec parameters on RtpSenders

Features at risk for in 1.0 (may revisit in post-1.0 work)
----------------------------------------------------------
*Partial offers/answers (no discussion or progress in IETF or W3C -
probably not in scope for post-1.0 either since it seems we're moving
away from SDP)
*API for Simulcast/SVC
*https://github.com/w3c/webrtc-pc/issues/4 CSRC added to RtpReceiver
*https://github.com/w3c/webrtc-pc/issues/5 indicate if temporal or
spatial video quality is most important - RtpSender
*ICE pool size
*Worker support for data channel

Stefan for the chairs

[1]
https://lists.w3.org/Archives/Public/public-webrtc/2013Dec/att-0076/Chairs__proposal_for_WebRTC_1.0_In_2FOut_-_W3C__1_.pdf

[2] http://www.w3.org/2015/06/webrtc-charter.html