Bernard: it would be a WG draft and people could comment on it?
Henrik: yes, not a mature spec
Youenn: if it remains a WD forever, whenever something is mature enough to go into webrtc-pc, it should go there
Bernard: when it gets implemented...
Youenn: that would be "living standard" roughly
Harald: consensus to adopt?
... Dom can rename the repo
... [RESOLVED] webRTC extensions spec adopted
Harald: I propose that we close
this issue
... objections?
Jan-Ivar: I need feedback from my SDP guys
[RESOLVED] 2313 is closed
Harald: add a comment to say if you send only, it's empty
Henrik: we should do it
<scribe> ACTION: Harald to create the PR for webrtc-pc issue 2369
Jan-Ivar: we can also get a race with a simulcast offer
Harald: if some unrelated function calls setParameters?
Jan-Ivar: it's asynchronous
... the parameters can only be changed asynchronously
Harald: between tasks, all functions will return all the same values of parameters?
Jan-Ivar: yes
... that's the intention
Harald: last time we discussed transactionId, it was seen as too obnoxious
Youenn: why can't we @@@1 ?
... A might not be a problem
Harald: it was considered a feature
Jan-Ivar: if you use higher level functions, state will be inconsistent
Henrik: There's more reason why it could fail, we could say it's a feature. The most user friendly way is to call setParameters and getParameters in the same task
Florent: it should be made more obvious in the API
Jan-Ivar: it will always fail,
quite obvious
... if lastReturnedParameters is not null, you're in the same
task
<scribe> ACTION: Jan-Ivar to create a PR for webrtc-pc issue 2315
Jan-Ivar: we could leave to
implementations, or mandate how implementations should respond
to this
... how do we interpret the new simulcast offer
... the options may not be compliant with JSEP
Henrik: my gut reaction is that order is significant
Harald: it should be a MUST
Jan-Ivar: we could decide that the remote offer should be trashed
Bernard: say you set 3 encodings
in setLocal, then you get an offer for 2, you do rollback, what
would happen? I doubt it would succeed
... we should try it
Jan-Ivar: the reason we added this in addTranceiver was that you need to drop it and create a new one if the layers change
Harald: I prefer to reject the remote offer
Henrik: to be consistent with addTransceiver we should reject
Jan-Ivar: if an SFU sends you a simulcast offer, then a few seconds later another one?
Bernard: that may happen
Jan-Ivar: JSEP says the offer MAY
propose a change
... do we want to forbid that?
Bernard: I guess RIDs would not
change
... I don't think we have a use case for this
Harald: it could be pushed to an extension spec
Henrik: we could say "execute as
.... JSEP except if RIDs change"
... in other places in the spec we amended JSEP processing
Jan-Ivar: it does not really contradict JSEP, which says "MAY"
RESOLUTION: if the RIDs change in the offer, we just fail SRD (issue 2314)
Henrik: you can see "completed"
as a subset of "connected"
... it's not distinct states
... I agree with the proposal to add a note
Jan-Ivar: "completed" means "completed but not connected"?
Henrik: no
... "completed" means "no more pair "
Proposal is accepted
<scribe> ACTION: Harald to make a PR for webrtc-pc issue 2316
Henrik: proposal is to remember
the transport slots and if you rollback you go back to the
previous transport
... When you have an offer, you have a transport created, if
you rollback you drop it
Jan-Ivar: I'll defer to implementors to implement this and I agree
RESOLUTION: accepted
Henrik: similar proposal
RESOLUTION: accepted
Henrik: if we don't support async change to parameters (earlier issue) problem solved
Henrik: proposal to close, no issue with rollback and ICE restart
Jan-Ivar: I opened another issue
(2370)
... I'd like to add an example of a Perfect Negotiation
Henrik: it'd good to have this part of the spec rather than just a blog post
RESOLUTION: add an example (issue 2370)
RESOLUTION: close issue 2367
Henrik: are we OK to have
RTCError with a different name?
... since nobody implemented these, should we mark
additionalFields as "at risk"?
Bernard: we could still say use the existing name and have the additional fields
<scribe> ACTION: Henrik to make a PR for webrtc-pc issue 2330
Youenn: proposal to move this
stat to the extension spec
... implementations that are already shipping and those not yet
shipping would still be compliant and we can still work on
improving
Henrik: it mostly contains stats
that are well-defined but for which we're not sure it's
useful
... we can adopt and refine
Harald: agreement?
RESOLUTION: move networkType to extension spec
Youenn: the device-info
permission can be granted forever
... browsers usually don't expose it to users
... only camera/microphone, not device-info
... the expected flow is to call gUM first
... proposal to replace that permission with a slot
... this slot can still be modified during the lifetime of the
page
... proposal in PR 641
Jan-Ivar: I like the concept.
Could we get the same effect by using feature policy?
... maybe extendability could be added to use it in other
specs
Harald: it's simpler. agreed
<scribe> ACTION: Youenn to update the PR 641 (MediaCapture and Streams)
Youenn: Expose no device
information at all by default
... Proposal for going to REC is status quo, not leaking
info
Jan-Ivar: The user can choose not to reveal the presence of a camera/microphone
Henrik: would it break websites?
Youenn: I don't know if it's the case
Henrik: I got the impression that
PING group is not happy with exposing info, even for backwards
compatibility
... we should fix the mistake
Jan-Ivar: FF has a pref for this, used in tor browser, which creates fake devices
Youenn: I can take the action to test a hacked webkit with an empty list and test a few sites
Henrik: throw an exception rather than returning empty list
Harald: it's a breaking
change
... all for experiments to see how it breaks
<scribe> ACTION: Youenn to experiment with hacked 'enumerateDevices' implementation
Jan-Ivar: concept of one-time permission
Henrik: all browsers should do the same
Harald: permissions prompt loops
Youenn: if you have the user click, then the user will be able to close the page
Jan-Ivar: we don't know the best behaviour yet
Jan-Ivar: expose info on all user
devices is much worse than browser fingerprinting
... you reveal all your devices in Safari, one device in
FF
... with PING proposal, FF would expose all labels, which may
be worse than current state
... intend is to expose only the chosen device label
... avoid granting all devices
... ask permission on changing the device
... for most users, having a selector is not good since they
have only 1 device of each type
... PR 644 mandate selector according to existing choices (see
table in slide)
Harald: it breaks currently deployed use cases
Youenn: I agree that there are potential regressions
Jan-Ivar: if you already know the devices that the user used last time, it goes back to existing case
Harald: we're stepping too far into the area of spec trying to mandate user interface
Bernard: yes
Jan-Ivar: in most of the cases,
it was the browser that was choosing for the user. Now we would
be asking the user
... granting the user the right to choose
... the benefit is that we can retire the labels from
enumerateDevices entirely
... the minimum is that user agents don't ask for permissions
for all devices
... or record denial on all
[out of time]