Re: Decisions and further work coming from Seattle f2f

We would also like to thank Microsoft for hosting the F2F in Redmond last
week.

We know these events do not come without considerable cost and countless
hours of administration, we are truly grateful.

Thank you!

Erik, for the chairs.


On Tue, Sep 15, 2015 at 2:50 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> This rather long mail has a few different objectives:
> - Make sure we got things recorded correctly
> - Inform those not present on the decisions made at the meeting (to
> allow for objections before making them formal)
> - Handshake with the Drivers of different PRs
> - Highlight what PRs need review. We want to underline the importance of
> this - the more eyes that look at each PR the better the quality. So
> please help out here, and even if you find no issues a simple “LGTM” is
> helpful.
>
> So please read this mail to the end, and inform us where we got it
> wrong, help by reviewing PRs that need review, speak up if you were not
> at the meeting and think some decision is wrong etc.
>
> The chairs
>
> Summary of decisions
> ====================
> Feature completeness WebRTC 1.0
> -------------------------------
> It was discussed and agreed that beyond what is documented further below
> (in forms of PRs that should be merged, or PRs to be created and
> eventually merged), and after clarifying the situation around simulcast,
> no new functionality should be added to WebRTC 1.0, except if it is
> determined that privacy or security related changes or enhancements are
> needed. Naturally there will still be a lot of changes to the document
> in the process towards CR (both editorial and fixing things that are
> broken), and the border between what is “new” and what is fixing
> something that exists can be blurry, but nevertheless the guiding
> principle is that WebRTC 1.0 (with the changes described below) is
> feature complete. One important reason for this decision is that the
> charter stops us from working on a next version until 1.0 reaches CR.
>
>
> PRs introducing new APIs/new functionality that _should_ be merged (note
> that we only discuss PRs that add functionality - there are many PRs
> that are of more editorial nature; also note that for simplicity we
> discuss in terms of PRs, the decisions are of course for the
> functionality those PRs introduce):
> ------------------------------------------------------------------------
> - PR270 ‘SCTPTransport object’ should be merged. Driver: Peter Thatcher.
> Status: needs review.
> - PR280 ‘ ICE Transport more readonly info’ should be merged. Driver:
> Peter Thatcher. Status: needs review.
> - PR273 ‘RTPSender more readonly info’ should be merged. Driver: Peter
> Thatcher. Status: needs update (before review).
> - PR291 ‘PC.connectionState’ should be merged. Driver: Peter Thatcher.
> Status: needs review.
> - PR237 ‘ReplaceTrack’ decided that replaceTrack should fail if the
> track could not be replaced without negotiation, but with that change
> replaceTrack should be merged. Driver: Jan-Ivar. Jan-Ivar has created
> PR303 to fix this. Status: needs review.
> - PR300 ‘CSRC and mixer client levels’. Should be merged. Driver: Cullen
> Jennings. Status: needs review.
> - PR284 ‘ICE errors’ should be merged. Driver: Justin Uberti. Status:
> Editors to review and hopefully merge.
> - PR289 ‘ICE Pool size’ should be merged. Driver: Cullen Jennings.
> Status: needs update (before review).
> - PR298 ‘codec reordering post negotiation’ should be merged. Driver:
> Peter Thatcher. Status: Editors to review and hopefully merge.
> - PR293 ‘addMedia/Transceiver’ should be merged. Driver: Peter Thatcher.
> Status: needs review.
> - PR269 ‘sender/receiver getCapabilities’ should be merged. Driver:
> Peter Thatcher. Status: needs review.
>
> New PRs to be created and (once reviewed and found OK) merged based on
> decisions at the meeting:
> ----------------------------------------------------------------------
> - PR for pre-negotiation codec selection. Driver: Martin Thomson.
> - PR for pre-warming (based on Transceiver). Driver: Peter Thatcher.
> - PR to add text describing how the RTPReceiver deals with early media.
> Driver: Peter Thatcher.
>
>
> PRs the meeting decided should be closed without merging:
> ---------------------------------------------------------
> - PR272 ‘RtpSenderInit’ will be closed without merging.
> - PR258 ‘Setting Codecs’ will be closed without merging. Discussion
> revealed that it should deal with codec reordering instead (PR298
> addressing this), and that we need a new PR for pre-negotiation codec
> selection.
> - PR292 ‘PC.onwarning / onfatalerror’ will be closed without merging. No
> need for this.
> - PR271 ‘PC warmup by track-free RTPSender’ will be closed without
> merging. Will develop alternative (based on Transceiver object) method
> for pre-warming.
> - PR279 ‘Replace OfferToReceive’ will be closed without merging.
> Transceiver object will solve this.
> - PR283 ‘unassignedmedia’ will be closed without merging. Instead new
> text will be added that describes how a RTPReceiver deals with early
> media (Peter responsible for this).
>
>
> Issue discussed at the meeting and found to need further work before a
> decision can be made:
> ===================================================================
> - Whether any support for simulcast is part of 1.0.
> For info: it seems that to some extent this is hinging on IETF MMUSIC
> work that is not ready. The proponents of simulcast in 1.0 is pushing
> for a virtual MMUSIC interim, and if that takes place and manages to fix
> the outstanding issues we may call for a WebRTC virtual meeting before
> TPAC to discuss simulcast in 1.0 further. A PR a week before the virtual
> meeting is a prerequisite.
>
>