Re: Scoping WebRTC 1.0

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

On Mon, Jun 29, 2015 at 11:31 PM, Stefan Håkansson LK <> 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
> * CSRC added to RtpReceiver
> * indicate if temporal or
> spatial video quality is most important - RtpSender
> *ICE pool size
> *Worker support for data channel
> Stefan for the chairs
> [1]
> [2]

Received on Tuesday, 7 July 2015 18:24:37 UTC