Re: Decisions and further work coming from Seattle f2f

There were two other PRs we decided to write, of which I agreed to be the
Driver:
- Add getCapabilities to RTCRtpReceiver.  I thought I would add it to the
one for RTCRtpSender, but that was already merged :).
- Add fields to RTCIceCandidate, such as component, ip, port, etc.



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.
>
>