Raw notes from VI that just ended

Ha all, thanks for attending. These are my raw notes:


107 new Issues filed as part of the reviews made

Soliciting feedback about stuff without implementation plans.

Stefan is scribing

Looking at slide 6-7 for the content

Slide 8 ... regarding track related Issues (Taylor)
------------------------------------------
a. what happens remotely when a track is removed on sending side?
what events fire on track?
Jan-Ivar: the spec has breaking changes (i.e. if ended is not more fired 
on track)
Bernard: the text also had a lot of references to "stop" which is ambiguous
J-I: my proposal is to add back stop. A new track would be supplied if 
data came in again as result of a new SDP O/A.
Cullen: apps should get info if direction changes, but the track should 
not be destroyed.
Bernard: now you get a "mute" event - is what you want Cullen? 
Transceiver.stop() is permanent
Cullen: I like that
J-I: much can be the reason for "mute"
PeterT: The app can just check the direction if it wants to know reason 
for "mute"
J-I: yes, but I think the spec is currently confusing for people using 
addTrack/removeTrack - not symmetrical
Justin: why does it matter if a dead track stays in the stream or not?
J-I: many many tracks can accumulate up in a stream
Justin: I wrote the spec text, and could not see a need for "removed"
Taylor: (garbled) can an ended track be removed from the stream?
J-I: use replaceTrack
..... (a lot of discussion) .....
Taylor: the issue is backward compatibility
PeterT: having a reciever serving different tracks at different times is 
probably a can of worms
Adam: a sendonly transceiver also has a muted track on the receiver on 
the sending end, so this is not special
J-I: you get ghost tracks if you do a lot of addTrack/removeTrack. How 
can an app detect and remove those tracks.
Stefan: I hear support for keeping "muted" - but should we add counters 
to see if breaking apps is a problem?
Taylor: "muted" will fire with delay though. Main question is if need to 
handle backward compatibility.
PeterT: what if the track gets removed from the stream as result of 
removeTrack and change of transceiver direction attribute

ACTION: Jan-Ivar to work on PeterT's idea.
ACTION: Chrome team, Firefox team: look into adding counters to see if 
not firing "ended" is a real issue

Shijun: I like Peter's proposal too (Adam also does +1)

Taylor: I think this only solves the problem for some people, question 
is if it is worth doing anything at all.
Cullen: stream provides sync context for tracks
J-I: not synced presently

Next slide (10) Issue 1207: discontinuity when setting remote description.
SDP munging could be used, but we want to avoid that.
PeterT: what about not having setRD not blowing away preferences?
Cullen: we argued for blowing it away since what you had may not be 
compatible with the new offer
XXX: is this specific for codecs, or broader? We're currently struggling 
with rids with setParameters in combination with negotiation
Taylor: I think the problem you are describing is a different one. But I 
need to think it through
J-I: rid is not modifyable via setParameters

ACTION: Taylor to draft text for preferences not being blown away (and 
explain how that works when the new offer contains codecs that are 
completely different than the original one)

Data Channel:
-------------
Issue 1287 data cannot be sent (slide 12)

Proposal: don't close data channel, but throw error if buffer is full.
Randell: I'm generally OK with the proposal. The problem is if apps 
don't handle the exception and believe data was sent. But this makes sense.
Cullen: I'm also in favor of this change.

Decision: we should merge PR #1209

Issue 1148: skipped based on previous decision


DTLS failuers
--------------
Slide 15. Issue#1092/PR#1115
Cullen: we need to report fingerpring failure, the question is only in 
which container and it shoudl be done DTLSTransport
Bernard: are there objections to the PR#1115?
Taylor: I don't see the need for a separate event if it can be covered 
by an alert
Cullen: is there any way to find out why fingerprint failed?

Conclusion: we need to clarify some distinctions in PR #1115

Issue 1250/Slide 16. Is there a need to obtain default certificates?
J-I: what can they be used for?
Bernard: I do not have a use case for this.

Meeting consensus to not do the change #1250 proposes.

Slide 17/Issue#1159/PR#1160: Proposal is to remove getAlgorithm.
Cullen: OK, but remember that the browser needs to remember between 
sessions. Very convenient to have though. Is it difficult to implement?
Bernard: Henrik and Martin have complained. No one has implemented, and 
a lot of pain to implement. Can we skip?

Meeting consensus to remove getAlgorithm, i.e. merge PR#1160.

Received on Wednesday, 7 June 2017 16:35:31 UTC