IRC log of webrtc on 2019-09-18

Timestamps are in UTC.

23:34:30 [RRSAgent]
RRSAgent has joined #webrtc
23:34:30 [RRSAgent]
logging to https://www.w3.org/2019/09/18-webrtc-irc
23:34:35 [dom]
RRSAgent, make log public
23:34:41 [dom]
Meeting: WebRTC TPAC F2F Day 1
23:34:46 [dom]
RRSAgent, this meeting spans midnight
23:34:53 [dom]
Chair: Bernard, Jan-Ivar, Harald
23:34:54 [dom]
Present+
23:36:17 [dom]
Present+ jeff
23:36:42 [ericc]
ericc has joined #webrtc
23:38:25 [dom]
Present+ Youenn, EricC, Harald, Orphis, Bernard, Jan-Ivar, Henrik, Armando, Emad
23:40:00 [dom]
-> https://docs.google.com/presentation/d/1Xprz0ElNTUWRDdX6kyp11cZ4ItTvUFUmzoXsKZdXxuU/edit#slide=id.p Meeting slides
23:40:09 [jib]
jib has joined #webrtc
23:40:48 [youenn]
youenn has joined #webrtc
23:40:51 [dom]
ScribeNick: youenn
23:40:56 [youenn]
WebRTC F2F Thursday morning
23:40:59 [dom]
Topic: Agenda review
23:42:41 [hhan__]
hhan__ has joined #webrtc
23:42:48 [dom]
Topic: State of the WebRTC WG
23:44:20 [youenn]
Slight difference between charter ending March 2020 and list of deliverables.
23:44:30 [youenn]
Probably not able to deliver everything
23:44:53 [youenn]
Web developers want interop, it should just work
23:46:53 [youenn]
media capture main spec: 26 issues, 21 of them sticking around, probably harder to fix.
23:48:20 [youenn]
community sense is that it works.
23:48:35 [Jared]
Jared has joined #webrtc
23:49:50 [youenn]
Going to PR requires closing bugs and validating testing.
23:50:10 [youenn]
screen capture spec
23:50:44 [youenn]
developer use it and sense is that it works.
23:51:05 [youenn]
We should get it to CR.
23:51:23 [youenn]
13 open bugs.
23:51:36 [youenn]
dom: need full horizontal review
23:51:54 [youenn]
Goal is to fix all CR blocking issues by ending of F2F
23:52:20 [youenn]
Need also to fill out TAG review.
23:53:29 [youenn]
Need an explainer for the TAG review
23:53:44 [youenn]
webrtc-pc!
23:54:34 [youenn]
32 open issues, still new ones coming in at a good pace
23:55:12 [youenn]
Bugs are smaller and smaller
23:57:14 [youenn]
New PR target at the end of F2F
23:57:25 [youenn]
WebRTC-identity
23:57:55 [youenn]
Not much progress there
23:59:26 [dom]
Present+ Jared
00:02:02 [jeff_]
jeff_ has joined #webrtc
00:04:11 [youenn]
Other documents
00:04:22 [youenn]
Capture from DOM
00:04:54 [youenn]
Needs editor.
00:05:00 [dom]
https://github.com/w3c/mediacapture-fromelement/
00:05:22 [youenn]
19 open issues, fairly old but heavy use.
00:06:17 [youenn]
Need TAG/privacy/security review and check open bugs whether blocker or not
00:06:32 [youenn]
media recorder API
00:06:49 [youenn]
Need an editor and TAG review.
00:07:42 [youenn]
stat-identifier
00:07:54 [youenn]
... spec: fairly active
00:09:22 [youenn]
depth spec: no more progress, shipped in chromium under a pref.
00:10:12 [youenn]
audio output devices: shipped in Chrome, Mozilla under a pref.
00:10:31 [youenn]
... in CR
00:10:33 [anssik]
anssik has joined #webrtc
00:11:00 [youenn]
content hints: released in Chrome, works, WD
00:12:33 [youenn]
DSCP: origin trial showed mixed results, especially in private networks
00:13:25 [youenn]
WebRTC-SVC: active interest, early in development cycle
00:14:13 [youenn]
WebRTC-ICE: Implemented in Chrome as part of QUIC experiment. Basic stuff working.
00:14:20 [youenn]
No first WD yet.
00:15:59 [youenn]
Other W3C activity: media wg activity is relevant to WebRTC WG
00:17:51 [youenn]
TOPIC: WebRTC 1.0 Testing
00:20:33 [inamori_]
inamori_ has joined #webrtc
00:23:28 [hta1]
hta1 has joined #webrtc
00:24:48 [youenn]
Specs have links to tests, should allow to compute spec coverage.
00:27:10 [youenn]
A lot of progress in tests passing in all 4 browsers.
00:32:33 [youenn]
DrAlex presenting the WPT and KITE dashboards
00:35:24 [inamori_]
inamori_ has joined #webrtc
00:35:45 [youenn]
Simulcast testing big progress with IETF 104 and 105 hackathons.
00:47:16 [youenn]
Topic: Next steps to PR for WebRTC-pc
00:51:10 [youenn]
Chrome has mid and rid header extensions, Firefox supports rid header extension.
00:52:30 [youenn]
Florent implemented the simulcast playground for unified plan.
00:52:38 [youenn]
Could be used as a basis for WPT.
00:53:32 [youenn]
ACTION: Florent to investigate upstreaming his page as WPT test
00:53:32 [trackbot]
Created ACTION-124 - Investigate upstreaming his page as wpt test [on Florent Castelli - due 2019-09-26].
00:55:05 [dom]
-> https://dontcallmedom.github.io/webrtc-impl-tracker/?webrtc Confluence-based WebRTC Implementation tracker
00:59:51 [Max_]
Max_ has joined #webrtc
01:02:38 [youenn]
Plan: do a final CR containing all new changes, then no substantive changes. Then validate testing is sufficient to go in PR.
01:03:17 [youenn]
Goal is to go to PR by end of the year.
01:05:59 [jianjunz]
jianjunz has joined #webrtc
01:29:32 [horiuchi]
horiuchi has joined #webrtc
01:32:22 [horiuchi]
horiuchi has joined #webrtc
01:39:01 [hhan]
hhan has joined #webrtc
01:40:58 [jib]
jib has joined #webrtc
01:41:10 [youenn]
Topic: Issue 1764
01:41:21 [youenn]
Bernard summarizing the issue
01:42:10 [Gooroomee]
Gooroomee has joined #webrtc
01:42:32 [youenn]
Discussing Nils proposal.
01:42:49 [youenn]
Harald: are all codecs ok with sending, then not sending and resending audio packets?
01:43:24 [youenn]
Opus: you need to process a few packets before outputting sounds?
01:43:30 [youenn]
s/sounds?/sound/
01:43:47 [jeff]
jeff has joined #webrtc
01:44:34 [youenn]
Varun: what about doing like in mute case?
01:45:07 [youenn]
Bernard: send silence is not very clear, might change according the negotiated parameters.
01:48:17 [youenn]
RESOLUTION: Accept Nils proposal for Issue 1764
01:48:37 [youenn]
Topic: Issue 2121
01:57:08 [horiuchi]
horiuchi has joined #webrtc
01:59:15 [youenn]
RESOLUTION: Proposal C: define retrieval of constraint properties for getSettings but make them not modifiable
01:59:48 [jib]
for width, height and frameRate, and aspectRatio
02:00:13 [youenn]
Issue 2230
02:00:21 [dom]
trackbot, bye
02:00:21 [trackbot]
trackbot has left #webrtc
02:00:39 [dom]
Youenn: the host field in the ice error event exposes private ip addresses
02:01:05 [dom]
... in theory it could expose private information; in practice, it's exposing addresses that in general would have already been exposed to the page
02:01:17 [jeff]
jeff has joined #webrtc
02:01:19 [dom]
... the spec opens up the possibility to use 0.0.0.0:0 if filtering is needed
02:01:28 [dom]
... there is an odd case when you ask only for relay candidates
02:01:39 [dom]
... we could maybe filter the host address in that case
02:01:52 [dom]
... returning 0.0.0.0:0 instead of null is a bit strange
02:02:01 [dom]
... and why is port and address in a single field?
02:02:42 [horiuchi_]
horiuchi_ has joined #webrtc
02:02:43 [nakakura]
nakakura has joined #webrtc
02:03:40 [dom]
jan-ivar: maybe either than null, an empty string?
02:03:56 [dom]
harald: the advantage of 0.0.0.0:0 is that it is parseable by an IP address parser
02:04:15 [dom]
... e.g. if you log the errors
02:06:28 [ericc]
ericc has joined #webrtc
02:07:37 [dom]
dom: since it has been very recently deployed, this is purely a cosmetic design decision at this point
02:07:47 [dom]
jan-ivar: empty string sounds good to me
02:08:37 [dom]
henrik: we should be consistent with what we have in RTCIceCandidate
02:09:12 [dom]
RESOLUTION: empty string for null value, split port separately
02:10:59 [dom]
(make port nullable, find name for host)
02:11:08 [dom]
ISSUE 2257
02:14:01 [youenn]
Same certificate for workers so postMessage is potentially useful.
02:14:37 [youenn]
Bernard: for forking, same certificate for different endpoints, potentially in a worker thread.
02:19:41 [youenn]
RESOLUTION: Keep the existing ability and put a note about the security issue.
02:21:08 [Zakim]
Zakim has left #webrtc
02:21:24 [youenn]
postMessaging a certificate might be useful in a data channel context so it might be a useful feature.
02:24:40 [youenn]
Topic: Screen capture
02:25:34 [youenn]
Jan-Ivar is listing the list of improvements done in the past year.
02:26:15 [youenn]
Issue 60: Define Tab Capture
02:27:36 [Riju]
Riju has joined #Webrtc
02:27:53 [youenn]
RESOLUTION: Use 'browsing context' as tab capture
02:29:48 [youenn]
Need horizontal review, fill out privacy and security questionnaire. Need explainer.
02:31:15 [youenn]
Discussion about tab capture. Mozilla might want to capture the active tab (without the other tabs like a window would leak).
02:32:48 [youenn]
Potential clarification: make it clear that tab capture might change the the tab dynamically.
02:35:20 [horiuchi]
horiuchi has joined #webrtc
02:36:08 [youenn]
Topic: Media capture and streams
02:36:12 [youenn]
Issue 554
02:41:42 [youenn]
Harald: lack of spec actually makes it harder to implement. Definitely interested and would like to push implementation when there is a spec.
02:41:55 [youenn]
Jan-Ivar: Would be good to have for our own testing.
02:42:11 [dom]
Issue 565
02:45:13 [dom]
RESOLUTION: allow browsers not to fire devicechange event if the list of device is actually the same
02:46:21 [dom]
make this mandatory behavior unless this can be privacy-neutral
02:46:25 [youenn]
Issue 584
02:46:50 [Max_]
Max_ has joined #webrtc
02:50:58 [horiuchi]
horiuchi has joined #webrtc
02:53:05 [youenn]
Safari has potential issues with downscale restriction in multiple apps accessing to camera.
02:53:58 [youenn]
RESOLUTION: Remove upscale from the proposed sentence and merge
02:56:18 [youenn]
Issue 608
02:58:29 [jianjunz]
jianjunz has joined #webrtc
03:01:57 [jeff_]
jeff_ has joined #webrtc
03:02:08 [Riju]
Riju has joined #Webrtc
03:02:42 [ericc]
ericc has joined #webrtc
03:02:57 [youenn]
Topic: Media Recording
03:03:01 [youenn]
ISSUE 139
03:06:39 [youenn]
Proposal is to always re-encode when mimeType is set and not reencode otherwise.
03:09:36 [yuj]
yuj has joined #webrtc
03:10:19 [youenn]
RESOLUTION: Consensus from Proposal B
03:10:25 [youenn]
s/from/for/
03:10:48 [nakakura]
nakakura has joined #webrtc
03:11:28 [youenn]
Issue 167
03:13:52 [horiuchi]
horiuchi has joined #webrtc
03:15:22 [horiuchi_]
horiuchi_ has joined #webrtc
03:19:50 [dom]
RRSAgent, draft minutes
03:19:50 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom
03:19:55 [youenn]
RESOLUTION: Start with proposal B, Jan-Ivar to create a PR, promise based.
03:20:14 [youenn]
Need to discuss multiple track change cases.
03:20:19 [dom]
RRSAgent, draft minutes
03:20:19 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom
03:31:25 [horiuchi]
horiuchi has joined #webrtc
03:39:51 [horiuchi]
horiuchi has joined #webrtc
03:44:06 [horiuchi_]
horiuchi_ has joined #webrtc
04:09:07 [yj]
yj has joined #webrtc
04:09:14 [inamori_]
inamori_ has joined #webrtc
04:14:00 [ericc]
ericc has joined #webrtc
04:19:36 [yj]
yj has joined #webrtc
04:21:28 [jeff_]
jeff_ has joined #webrtc
04:23:55 [hta]
hta has joined #webrtc
04:29:21 [nakakura]
nakakura has joined #webrtc
04:29:43 [dom]
Topic: WebRTC Stats
04:30:20 [dom]
henrik: [implementation status] - the gaps in implementation reflects more structural changes in where the stats are exposed rather than the lack of available metrics
04:30:46 [jib]
jib has joined #webrtc
04:31:11 [steveanton]
steveanton has joined #webrtc
04:31:14 [dom]
ScribeNick: steveanton
04:32:50 [horiuchi]
horiuchi has joined #webrtc
04:33:12 [steveanton]
youenn: wpt should be enough for simple counters
04:33:37 [steveanton]
youenn: WebKit has some basic wpt validation that can be upstreamed
04:33:56 [steveanton]
hbos: chrome does not have detailed tests at the integration level
04:34:28 [dom]
ACTION: Youenn to upload simple validation tests from webkit to WPT
04:34:33 [steveanton]
vr000m: explore simple tests in wpt then go forward from there
04:34:59 [ericc]
ericc has joined #webrtc
04:36:04 [hhan]
hhan has joined #webrtc
04:37:17 [horiuchi]
horiuchi has joined #webrtc
04:38:39 [steveanton]
bernard: new model better supports SVC
04:38:53 [jeff]
jeff has joined #webrtc
04:39:23 [steveanton]
topic: issues 361/452
04:40:12 [steveanton]
general agreement to proceed
04:40:20 [steveanton]
topic: issues 478/396
04:41:06 [steveanton]
youenn: can already get this information from the api
04:41:16 [steveanton]
jib: opposed for stats reporting things that the app already knows
04:41:42 [steveanton]
hbos: need mid to correlate stats objects with the m= section (proposal 2)
04:42:44 [steveanton]
jib: adding transceiver stats requires adding transceiver id
04:43:37 [steveanton]
bernard: snapshotting state would help correlate stats with changes in signaling
04:44:39 [steveanton]
jib: worried about bloat in stats objects
04:46:03 [steveanton]
vr000m: two issues (1) do we need a transceiver dictionary (2) once we have that do we need additional data e.g. direction
04:46:44 [steveanton]
jib: could also just put a mid on sender/receiver
04:48:38 [steveanton]
vr000m: stats are used largely for debugging
04:52:59 [steveanton]
agreement that mid should be mti
04:54:41 [steveanton]
jib: opposed to direction/currentDirection more than opposed to transceiver stats
04:55:17 [steveanton]
general agreement to add transceiver stats to with mid/sender id/receiver id only
04:55:42 [vr000m]
also codecIds?
04:55:56 [steveanton]
TOPIC: issue-480/issue-472
04:59:00 [steveanton]
bernard and jib sold on proposal 1
05:01:02 [Riju_]
Riju_ has joined #webrtc
05:01:21 [steveanton]
vr000m: like events since we then we don't have to shim peerconnection
05:02:24 [steveanton]
youenn: prefer that stats expose replace track info directly rather than through events
05:02:41 [Amit]
Amit has joined #webrtc
05:06:01 [steveanton]
jib: see that shimming replacetrack is not ideal, but does work
05:09:12 [steveanton]
vr000m: not providing something like onstatsended leaves a gap with replacetrack that has been known for 2 years
05:09:49 [steveanton]
youenn: onreplacetrack should be a follow up and not in 1.0
05:11:37 [jeff]
jeff has joined #webrtc
05:12:44 [jianjunz]
jianjunz has joined #webrtc
05:13:40 [steveanton]
RESOLUTION: remove onstatsended and continue discussion about an event to notify when significant stats change
05:13:47 [steveanton]
TOPIC: issue-479
05:18:15 [steveanton]
RESOLUTION: consensus to remove track stats (moving it to obsolete section)
05:18:36 [steveanton]
TOPIC: Content-Hints
05:23:02 [steveanton]
TOPIC: issue-2248
05:28:41 [steveanton]
TOPIC: issue-28
05:33:08 [steveanton]
TOPIC: issue-28 & issue-30
05:33:11 [horiuchi]
horiuchi has joined #webrtc
05:35:57 [horiuchi_]
horiuchi_ has joined #webrtc
05:36:23 [steveanton]
hta: more sympathetic to normative action than before
05:36:55 [steveanton]
hbos: agree that we should only ship APIs that are well defined
05:38:08 [Gooroomee]
Gooroomee has joined #Webrtc
05:38:09 [steveanton]
jib: trying to be agnostic about what to do next, just want to provide feedback
05:38:55 [steveanton]
bernard: where to specify normative hints for content hints?
05:39:59 [steveanton]
jib/hta/bernard: content hints should be a follow up spec that covers the integrations with other specs
05:40:34 [steveanton]
youenn: is a high level api that influences control knobs the right design?
05:43:26 [Riju]
Riju has joined #webrtc
05:43:33 [steveanton]
youenn: if hints are crucial for an application then we should specify the behavior
05:44:17 [steveanton]
jib: hints can be useful since they are simpler than turning all the knobs
05:45:46 [steveanton]
TOPIC: disposing of content-hint
05:46:53 [steveanton]
bernard: some advanced codecs have content capture tools (hevc, av1)
05:47:02 [steveanton]
bernard: useful to expose this for e.g. screensharing
05:47:29 [steveanton]
RESOLUTION: advance but not at high priority
05:47:43 [horiuchi]
horiuchi has joined #webrtc
05:48:03 [steveanton]
TOPIC: DSCP API
05:53:03 [steveanton]
RESOLUTION: proposal 1
05:53:22 [steveanton]
(Move Priority to DSCP document, harmonize, keep experimenting)
05:53:33 [steveanton]
TOPIC: WebRTC-ICE
05:53:58 [horiuchi_]
horiuchi_ has joined #webrtc
05:54:50 [horiuchi]
horiuchi has joined #webrtc
05:56:37 [steveanton]
youenn: not as opposed to adopt as last year, but not sure if it's the right time (don't want to delay from finishing 1.0)
05:57:06 [steveanton]
dom: shouldn't be a high cost to the working group
05:58:22 [steveanton]
generally no opposition to adopting the spec
06:07:18 [horiuchi]
horiuchi has joined #webrtc
06:10:25 [steveanton]
bernard: do the p2p mesh folks want datachannels in workers?
06:12:12 [steveanton]
dom: does this expose new security & privacy risks?
06:12:23 [steveanton]
peter: need to think through the risks more
06:12:43 [steveanton]
bernard: forking has been thought through, but not in the context of p2p mesh
06:17:57 [steveanton]
bernard: who is asking for ICE forking? just dht people?
06:18:02 [steveanton]
hbos: why is ice forking hard?
06:20:00 [steveanton]
bernard: each transport has different candidate pair statuses, API changes (dtls transport) to facilitate forking, more ICE optimizations that are more important for forking
06:20:44 [steveanton]
bernard: might not be that complex if you started from scratch and knew what you wanted to do
06:21:35 [steveanton]
peter: two code bases which would need to implement forking
06:21:39 [steveanton]
no current plans for either to do it
06:22:35 [steveanton]
hta: not hearing much enthusiasm in the room
06:22:36 [jianjunz]
jianjunz has joined #webrtc
06:22:51 [steveanton]
jib: more use cases could motivate implementors
06:23:42 [steveanton]
bernard: p2p mesh is an issue in the use cases repo
06:25:44 [inamori_]
inamori_ has joined #webrtc
06:28:00 [horiuchi_]
horiuchi_ has joined #webrtc
06:32:32 [horiuchi_]
horiuchi_ has joined #webrtc
06:37:20 [ericc]
ericc has joined #webrtc
06:43:38 [dom]
Topic: Features at risk
06:43:41 [dom]
ScribeNick: dom
06:50:58 [dom]
JIB: Overview of feature at risks: there are about 12 features marked at risk
06:51:07 [sugi]
sugi has joined #webrtc
06:51:15 [dom]
... I'll present some of our options to manage features at risks
06:51:28 [dom]
.. if no implementation and no dev interest, we remove the feature
06:51:47 [dom]
... if no implementation but dev interest, we can leave the spec if we expect imminent implementation
06:51:53 [dom]
... if not, we can move to an extension
06:52:03 [inamori_]
inamori_ has joined #webrtc
06:52:31 [dom]
... We conducted an analysis of what was implemented where to identify which features should be at risk
06:52:42 [dom]
... focusing on things with fewer than 2 implementations and no clear implementation commitment
06:53:11 [dom]
... for instance, rollback has only 1 implementation, but there is one ongoing
06:53:25 [dom]
... [reviewing the list to check for possible mistakes]
06:55:16 [dom]
... VoiceActivityDetection is at risk - only one (buggy) implementation
06:55:22 [dom]
Bernard: does it negotiate CN?
06:55:26 [steveanton]
steveanton has joined #webrtc
06:55:28 [dom]
Henrik: checking it now
06:55:41 [Amit]
Amit has joined #webrtc
06:56:13 [dom]
JIB: OauthCredential is not implemented anywhere
06:56:42 [dom]
Henrik: re VoiceActivityDetection, what Chrome ships can be done via setParameters
06:56:55 [dom]
JIB: pranswer - 2 impl
06:57:12 [dom]
Youenn: not sure our implementation should really count; this may need to be marked at risk
06:57:20 [dom]
JIB: we're interested in implementing, but it hasn't been a priority
06:57:34 [dom]
... QoS priority is at risk
06:57:49 [dom]
... icecandidateerror?
06:58:12 [dom]
Henrik: it's shipped in Chrome and old-Edge
06:58:28 [dom]
Youenn: will need to be tested
06:59:03 [dom]
JIB: RTCError isn't shipped yet anywhere
06:59:40 [dom]
Henrik: we have the basic plumbing, but finalizing it is more work than you would expect
07:02:12 [dom]
Dom: how confident are we about this landing any time? any risk of later interop?
07:02:26 [dom]
Youenn: pages could break if they've started relying on existing error names
07:02:53 [dom]
... Should we instead specify what currently ships (if interoperable)
07:03:22 [dom]
Bernard: we designed RTCError to provide more details
07:04:17 [dom]
... Errors in operational services occur at a very high rate
07:06:10 [dom]
Dom: let's plan on discussing this tomorrow
07:06:37 [dom]
JIB: simulcast-aware stats?
07:06:41 [dom]
Henrik: spec is ready
07:06:50 [dom]
JIB: commitment from Edge and Firefox to implement
07:08:59 [dom]
... Are they MTI?
07:09:22 [dom]
Henrik: adopting them means changing the behavior in a backwards incompatible way
07:10:02 [dom]
JIB: statsended we decided to remove
07:10:12 [dom]
... setStreams?
07:10:20 [dom]
Orphis: in Chrome
07:10:29 [dom]
Youenn: planned for us
07:10:37 [dom]
JIB: us too, by the end of the year
07:11:19 [dom]
... RTCPeerConnectionIceEvent.url is only in Safari - any other implementation commitment?
07:11:36 [dom]
Bernard: I think we would want to do this for Edge/Chrome
07:11:51 [dom]
JIB: planned for us, but probably not by EOY
07:12:26 [dom]
JIB: Identity - in Stockholm, we reached a compromise to split identity into a separate spec
07:12:37 [dom]
... there are still a few normative ref from -pc to -identity
07:12:42 [dom]
... but still only one implementation
07:13:03 [dom]
... are we ok with that situation?
07:13:18 [dom]
Youenn: I think it should be marked at risk
07:13:35 [dom]
JIB: getDefaultIceServices - not implemented should be marked at risk
07:13:57 [dom]
... we have 28 MTI stats that show as not implemented in WPT, but probably just because they've moved recently and the tests need to be updated
07:14:16 [dom]
Youenn: Firefox and Chrome are the two main implementor for stats
07:14:25 [dom]
Armanda: does the tests need an update?
07:14:31 [dom]
s/a:/o:/
07:14:48 [dom]
JIB: no, but implementations need to catch up with stats
07:15:12 [dom]
... I don't think they should be in jeopardy because they moved
07:15:23 [dom]
... Firefox doesn't have track-stats yet
07:16:43 [dom]
Dom: is the list of MTI stats in -pc correct?
07:17:59 [dom]
Henrik: it will have to be updated to match the results of our stats discussion tomorrow
07:18:13 [dom]
JIB: OAuthCredentials?
07:18:37 [dom]
RESOLUTION: move OAuthCredential to extension
07:20:06 [dom]
JIB: negotiate for rtcpTransport? (issue 3 in spec)
07:20:32 [dom]
Harald: impl got nuked, too confusing
07:20:48 [dom]
RESOLUTION: negotiate for rtcpTransport to be removed
07:21:00 [dom]
JIB: VoiceActivityDetection?
07:21:08 [dom]
Henrik: over taken by events, let's remove
07:21:16 [dom]
RESOLUTION: remove VoiceActivityDetection
07:21:48 [dom]
JIB: getDefaultIceServers()?
07:22:05 [dom]
Youenn: move to an extension and wait for a proponent to push for an improved proposal
07:22:18 [dom]
JIB: getSUpportedAlgorithms?
07:22:26 [dom]
RESOLUTION: remove getSupportedAlgorithms
07:22:43 [dom]
JIB: SendParameters.priority?
07:22:49 [dom]
Orphis: remove
07:23:13 [dom]
RESOLUTION: remove SendParameters.priority and prioritytype enum
07:23:25 [dom]
RESOLUTION: remove ReceiveParameters.encodings
07:23:30 [dom]
Orphis: (they're pointless)
07:23:40 [dom]
JIB: EncodingParameters.dtx?
07:23:51 [dom]
Bernard: nobody implements
07:24:00 [dom]
Orphis: available via SDP munging for OPUS in Chrome
07:24:15 [dom]
Harald: let's drop it
07:24:49 [dom]
Orphis: this applies to ptime and codecpayloadtype should also be at risk
07:25:27 [dom]
Henrik: a large discussion: there would be a need to control the codecs you sent beyond what to do with negotiation today
07:25:34 [dom]
Orphis: right now, it's read-only
07:26:04 [dom]
Henrik: codecpayloadtype could be removed and brought back later if there is demand in an extension
07:26:15 [dom]
Orphis: ptime isn't implemented, not clear demand
07:26:40 [dom]
RESOLUTION: Remove .dtx, .ptime, .codecpayloadtype from EncodingParameters
07:26:49 [dom]
RESOLUTION: datachannel priority to be removed
07:28:36 [dom]
Dom: Identity - mozilla sole implementor?
07:28:44 [dom]
JIB: we want to see it adopted
07:29:32 [dom]
... the peerIdentity steps could perhaps be moved to -identity
07:29:58 [dom]
Henrik: moving out is an editorial question
07:30:08 [dom]
... but the real question is whether identity is part of 1.0
07:30:22 [dom]
Youenn: no plan to implement in 1.0; interested in the field, but not sure this is the right solution
07:30:37 [dom]
... there may be other issues that need to be addressed with higher priority
07:31:10 [dom]
... we don't want to be tied to that particular solution at this time
07:32:14 [dom]
RESOLUTION: migrate the remaining identity steps to -identity
07:33:20 [dom]
Dom: we also need to figure out how to re-integrate isolated media streams into our normative sphere
07:34:18 [dom]
RRSAgent, draft minutes
07:34:18 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dom
07:35:14 [dom]
Topic: Developer feedback
07:35:22 [jib]
jib has joined #webrtc
07:36:32 [horiuchi]
horiuchi has joined #webrtc
07:37:46 [Riju]
Riju has joined #webrtc
07:39:56 [jianjunz]
jianjunz has joined #webrtc
07:46:21 [horiuchi]
horiuchi has joined #webrtc
08:22:37 [lgrahl]
lgrahl has joined #webrtc
08:32:45 [horiuchi]
horiuchi has joined #webrtc
08:34:37 [horiuchi]
horiuchi has joined #webrtc
08:34:47 [dontcallmeDOM]
dontcallmeDOM has joined #webrtc
08:37:36 [horiuchi_]
horiuchi_ has joined #webrtc
08:41:17 [horiuchi]
horiuchi has joined #webrtc
08:42:19 [hta]
hta has joined #webrtc
08:43:43 [dontcallmeDOM]
Topic: Mészáros Mihály’s Developer Feedback
08:43:43 [dontcallmeDOM]
Mészáros: TURN for NRENs, Higher education & research.
08:43:43 [dontcallmeDOM]
... Global turn server, the goal is to keep media traffic in their network.
08:43:43 [dontcallmeDOM]
... Multi-tenant TURN is not possible without Long Term Credential.
08:43:43 [dontcallmeDOM]
... Working on co-located TURN, working on implementation in Firefox and possibly Chrome.
08:43:44 [dontcallmeDOM]
... Why not just add these three attributes, it would require little changes to mechanisms. Should be little effort.
08:43:47 [dontcallmeDOM]
... We should consider keeping OAuth until we have alternatives for TURN.
08:43:49 [dontcallmeDOM]
Dom: Pressure to reach 1.0. Moving this out of the spec does not mean it is not going to happen, but we will need people to get involved to make sure spec and implementations are maintained. And write tests. We will likely reach out to you about future involvement.
08:43:53 [dontcallmeDOM]
Youenn: You say the existing API is not great, but is the current API working as a hack?
08:43:55 [dontcallmeDOM]
Mészáros: We use short term credentials and the behave TURN REST draft but I am not happy with this, there is a better way. We rely on the non-standard.
08:43:58 [dontcallmeDOM]
Harald: Do any of the browsers implement the behave TURN REST? How do you do this with current implementations of browsers?
08:44:01 [dontcallmeDOM]
Mészáros: It would be nice to have one authentication server anywhere.
08:44:05 [dontcallmeDOM]
Topic: Sean’s Developer Feedback
08:44:07 [dontcallmeDOM]
Sean: I work on a go implementation of WebRTC. A lot of people come with complaints about how they want their ICE to work. There’s so much going on.
08:44:10 [dontcallmeDOM]
... Small businesses want to use WebRTC but they have to use other things because they have restricted port ranges.
08:44:13 [dontcallmeDOM]
... Once a week someone complains about addIceCandidate before setRemoteDescription. Can we catch them or throw them in a queue? Re-order operations? It would save new developers a lot of time.
08:44:16 [dontcallmeDOM]
Jan-Ivar: The reason you can’t do addIceCandidate in a different order they could end up in the first offer.
08:44:19 [dontcallmeDOM]
Sean: That’s only an issue for the first offer.
08:44:21 [dontcallmeDOM]
Jan-Ivar: There’s no limitation you can only negotiate once. There’s a race potential: If you get a remote offer you have to set it before you await other operations.
08:44:24 [dontcallmeDOM]
Sean: In the real world this is a problem. People cache candidates for example. Jan-Ivar: You shouldn’t cache.
08:44:27 [dontcallmeDOM]
Sean: Closing (message+code) can be done by sending a final message
08:44:29 [dontcallmeDOM]
... Ability to deny a data channel based on data channel name. Not sure if enough value.
08:44:31 [dontcallmeDOM]
... Media via DataChannels is being more and more popular. Lack of HW acceleration.
08:44:35 [dontcallmeDOM]
... Some people would be happy with more latency for less packet loss? Both reliable and unreliable data channels. People want more flexibility than they can get with the current APIs.
08:44:38 [dontcallmeDOM]
... People want setCodecPreferences; SDP munging is painful. I’m tired of seeing people munge SDP and it blows up in their face.
08:44:41 [dontcallmeDOM]
... Lack of CipherSuite choices: people want HW acceleration.
08:44:43 [dontcallmeDOM]
... addStream vs addTrack vs addTransceiver. Causes headaches, people don’t understand what’s going on.
08:44:45 [dontcallmeDOM]
... Provisional offers/answer: Do we need them? I have to answer questions about it all the time.
08:44:47 [dontcallmeDOM]
... Can we make API simpler for porting to other languages like not having to use strings?
08:44:49 [dontcallmeDOM]
... Tor Snowflake uses DataChannels and spend a lot of time removing the ability to fingerprint. Can we set ciphers?
08:44:52 [dontcallmeDOM]
Topic: Silvia’s Developer Feedback
08:44:54 [dontcallmeDOM]
Silvia: Mostly complaining about things from a WebRTC Telemedicine developer’s point of view. We have to jump through hoops to make things interoperable! Chrome, Firefox, Safari.
08:44:57 [dontcallmeDOM]
... We have to recommend people not to use Firefox due to worse media quality. High-level report; don’t know why this is the case.
08:45:00 [dontcallmeDOM]
... We use the new API, using multiple streams works well in Chrome but not in Firefox. Interop problems.
08:45:02 [dontcallmeDOM]
... We sometimes hit decoding problems.
08:45:06 [dontcallmeDOM]
... Stats is a pain point: new getStats has much less information than the old one. Plus different browsers have different implementations of the standard getStats API as well.
08:45:09 [dontcallmeDOM]
... The API doesn’t really tell you whether or not media is flowing. We look at time of the media elements, usually it works but not always. It’s hard to detect playback issues. Any suggestions on finding out if media disappeared? The browser thinks the connection is there but we’re not receiving any frames.
08:45:13 [dontcallmeDOM]
... Data channels for video: You don’t have to deal with a lot of complexities. Interoperability is combinatorially more complicated when you have to deal with all the different versions of the specs.
08:45:16 [dontcallmeDOM]
Topic: Emil’s Developer Feedback
08:45:18 [dontcallmeDOM]
Emil: Will put in slides after the meeting. I have three items:
08:45:20 [dontcallmeDOM]
... One of the pain points: messiness around switching “plans” (Plan B vs Unified Plan). This does not solve any problems for us; it would be good to ensure this could be done gradually. Like SSRCs vs RIDs: it would be good to have SSRCs in the meantime while SFUs upgrade to RID support.
08:45:24 [dontcallmeDOM]
... We keep hearing not all windows are sharable on windows.
08:45:26 [dontcallmeDOM]
... As an SFU provider we want to assist call quality. Take audio quality for example, there’s really no way for us to improve audio quality. For video it’s simpler but limited. We would like to be able to add our own FEC to PeerConnection. Those hooks discussed a few years ago by Justin would be really nice. We would like to do End-to-End Encryption. Harald’s proposal is compatible with our goals. We would like hooks on the client side at diff
08:45:31 [dontcallmeDOM]
erent points in the pipeline to add our own logic.
08:45:35 [dontcallmeDOM]
Topic: “Others on the Line”: Max
08:45:37 [dontcallmeDOM]
Max: Lack of granular port ranges.
08:45:39 [dontcallmeDOM]
... How do we add hooks on different parts of the stack. We are excited about these things becoming part of the standard and
08:45:42 [dontcallmeDOM]
... Currently stuck on Plan B and is experiencing difficulties shipping Unified Plan, especially around SSRCs vs RIDs, but plan is to move to MID/RID multiplexing architecture.
08:45:45 [dontcallmeDOM]
Harald: Do you think we should revive SSRC signaling? Should we revive the draft that I wrote?
08:45:47 [dontcallmeDOM]
Max: Yes. Loudly adding a plus one!
08:45:49 [dontcallmeDOM]
i/Topic: Mészáros/ScribeNick: dontcallmeDOM
08:45:51 [dontcallmeDOM]
RRSAgent, draft minutes
08:45:51 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dontcallmeDOM
08:47:13 [dontcallmeDOM]
Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_19-20_2019#F2F_during_W3C_TPAC_2019
08:47:19 [dontcallmeDOM]
RRSAgent, draft minutes
08:47:19 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/18-webrtc-minutes.html dontcallmeDOM
08:53:53 [achronop]
achronop has joined #webrtc
08:58:39 [horiuchi]
horiuchi has joined #webrtc
09:00:52 [achronop]
achronop has joined #webrtc
09:02:04 [horiuchi]
horiuchi has joined #webrtc
09:02:31 [horiuchi]
horiuchi has joined #webrtc
09:03:13 [achronop]
achronop has joined #webrtc
09:04:54 [mp__]
mp__ has joined #webrtc
09:05:40 [mp__]
mp__ has joined #webrtc
09:23:19 [horiuchi]
horiuchi has joined #webrtc
10:00:26 [inamori_]
inamori_ has joined #webrtc