<vivien> (recording in progress)
Jan-Ivar: two use cases (recv-only, negotiate a track where ontrack fires remotely so you can use replaceTrack later). Is happy to leave default as 'send-recv'.
Cullen: would a change break existing code?
Stefan: FF nightly uses send-recv default.
Stefan: consensus for send-recv default.
Stefan: For the question "Should replaceTrack work if no track was ever attached?" conclusion is 'yes'. Any objections?
RESOLVED: Jan-Ivar to create a PR to clarify replaceTrack interaction with Direction/CurrentDirection.
Bernard and Cullen: no disagreement
Will discuss on the list how voice activity flag should be implemented.
<mt_____> fluffy: perhaps you can follow up with jib regarding voice activity in Firefox
<fluffy> glad to follow up on list about what needed implement the VAD
Jan-Ivar:Two potential choices: a or b
Choice b is relatively new, allows timestamps to be compared in workers, across pages
Are there concerns with choice b (time origin)?
Tim Panton: Is there an issue with timeOrigin and fingerprinting?
Fuzzing in sub-millisecond range...
Not a new problem in this use.
Adam: At TPAC, we were going to give advice to send at 1 fps
But in spec there is language that seems to indicate to send only one black frame.
<mt_____> why not "a black frame at a rate of 1 frame per second (video)" ?
Randall: on ended we should not
be sending video.
... If someone joins a conference, you want them to get a black
frame.
Adam: Send 1 fps in all cases?
Randall: Not certain I like it, but not certain I have an objection either.
Jan-Ivar: any concerns about lack of traffic?
Randall: consent should keep NAT binding open.
Cullen: Could have RTP disconnect
issues.
... A black frame takes no bandwidth, so no worries there.
Randall: what level of strength?
Adam: Should
<mt_____> why would one violate the SHOULD?
Adam: will create PR for review.
Issue 472: How to implement web-compatible camera downscaling?
Jan-Ivar: PR for resizeMode constraint.
PR does not include "box and scale" as suggested at TPAC.
Only "none" and "crop and scale".
Cullen: could have preference for "most pixels"
Jan-Ivar: Can push "box and
scale" to a separate issue.
... If you use a constraint, you get deterministic
behavior.
Being a constraint implies it can be retrieved via getSettings().
Stefan: More detail needed?
hta: decision is to merge, subject to detailed review
Issue 235: Is keeping stats around a memory problem?
<vivien> jib, we lost you on webex
First github goes down, then Jan-Ivar vanishes... related?
For discussion on the list.
Peter Thatcher on WebRTC-QUIC.
<mt_____> evidently my mic isn't working, but these states are different to those in the QUIC spec
<mt_____> unnecessarily
<mt_____> re: streams API, it is possible to use "implements ReadableStream" instead
<mt_____> I disagree, this isn't a question of taste, it's a matter of standardization
<mt_____> even if it were solved in a generic fashion, we would have to ensure that that generic mechanism were NOT available to the application through the browser, or it's turtles all the way down
<mt_____> I've implemented SLICE, it works
<mt_____> fluffy didn't like it, if I recall correctly
<fluffy> I like SLICE as long as browser controll timing of stuff that opens privacy or dos problems. The API peter has allows the JS to implement snowflake instead of ICE which I like way better than ICE
<lgrahl> fluffy: can you elaborate which timings you mean?
Martin: QUIC is still changing..
Cullen: On the other side, we want to think about RTC before QUIC is poured in concerete....
Peter: demuliplexing and multiple protocol discussions came about because of this discussion.
Martin: focus is on http in QUIC WG in short term.
Peter: WebRTC-QUIC spec can't be done before QUIC transport spec is done.
Martin: QUIC has a notion of version negotiation, API might want to expose that.
Cullen: what do we get with QUIC that we can't get with data channels?
Martin: approach so far is to provide QUIC generically...
Cullen: media over QUIC might have a higher firewall/NAT traversal rate.
Randall: agree (that we need crisp use cases).
Peter: There was significant interest at TPAC (though they didn't say why).
<lgrahl> the why is indeed one of the key things we should be interested in
Martin: QUIC does have some consent mechanisms... but may not be appropriate for p2p
Stefan: two minutes left in this section. How do we move ahead?
Peter: What does the WG want me to do between now and the next time we meet? And what is most important to discuss at that point?
hta: for ICE, getting security story clear.
Tim Panton: issue of drive-by webrtc connections (sent to mailing list).
Randall: looking at security is very important, shouldn't just be about ICE features.
Peter: Are you talking about SLICE?
Tim Panton: was thinking about whether we don't tie back to origin enough now.
<fluffy> So to summarize what we want Peter to do is bring us a different rock, seems like sort of an unfair request.
<vivien> We can reach the TAG on API guidance on using Streams API vs "implements ReadableStream"
(there is general support on the call for reusing the Streams API)
<lgrahl> late feedback from me regarding slice: i very much like that idea as it resolves a lot of use cases and optimisation issues (for example long-lived data channel use cases where battery usage is an issue)
<mt_____> fwiw, I agree with lgrahl: should we decide to integrate the stream API for data channels, it would be a stream per message
<lgrahl> yeah, i could provide a rough idea as an issue. that should clear up what i mean why this is different to the quic stream api
<mt_____> though there is an open question with data channels: are messages delivered in any particular order? if they are, then data channels might be a stream of streams
<mt_____> that should make it obvious how data channels are different from QUIC
<mt_____> for hta: CSP let's you at least enumerate the *origin* of data
<hta> mt: yeah, the difference is that features are a spec-time-defined namespace, while origins is a run-time-defined namespace
(there were discussion on security aspects and also on documenting use cases that would be solved with QUIC)
The Chairs are asking the WG particiapnts to read this new charter and either send their comments as Github issues with PR with proposed text edits or to open discussion on the group mailing list.