[minutes] TPAC F2F Sep 19, 20 2019


The minutes of our F2F meeting at TPAC last week are available at:
and copied as text below.



      [1] http://www.w3.org/

                         WebRTC TPAC F2F Day 1

19 Sep 2019




          dom, jeff, Youenn, EricC, Harald, Orphis, Bernard,
          Jan-Ivar, Henrik, Armando, Emad, Jared


          Bernard, Jan-Ivar, Harald

          youenn, steveanton, dom, dontcallmeDOM


     * [3]Topics
         1. [4]Agenda review
         2. [5]State of the WebRTC WG
         3. [6]WebRTC 1.0 Testing
         4. [7]Next steps to PR for WebRTC-pc
         5. [8]Issue 1764
         6. [9]Issue 2121
         7. [10]Screen capture
         8. [11]Media capture and streams
         9. [12]Media Recording
        10. [13]WebRTC Stats
        11. [14]issues 361/452
        12. [15]issues 478/396
        13. [16]issue-480/issue-472
        14. [17]issue-479
        15. [18]Content-Hints
        16. [19]issue-2248
        17. [20]issue-28
        18. [21]issue-28 & issue-30
        19. [22]disposing of content-hint
        20. [23]DSCP API
        21. [24]WebRTC-ICE
        22. [25]Features at risk
        23. [26]Developer feedback
        24. [27]Mészáros Mihály’s Developer Feedback
        25. [28]Sean’s Developer Feedback
        26. [29]Silvia’s Developer Feedback
        27. [30]Emil’s Developer Feedback
        28. [31]“Others on the Line”: Max
     * [32]Summary of Action Items
     * [33]Summary of Resolutions

   <dom> [34]Meeting slides


   <dom> ScribeNick: youenn

   WebRTC F2F Thursday morning

Agenda review

State of the WebRTC WG

   Slight difference between charter ending March 2020 and list of

   Probably not able to deliver everything

   Web developers want interop, it should just work

   media capture main spec: 26 issues, 21 of them sticking around,
   probably harder to fix.

   community sense is that it works.

   Going to PR requires closing bugs and validating testing.

   screen capture spec

   developer use it and sense is that it works.

   We should get it to CR.

   13 open bugs.

   dom: need full horizontal review

   Goal is to fix all CR blocking issues by ending of F2F

   Need also to fill out TAG review.

   Need an explainer for the TAG review


   32 open issues, still new ones coming in at a good pace

   Bugs are smaller and smaller

   <scribe> New PR target at the end of F2F


   Not much progress there

   Other documents

   Capture from DOM

   Needs editor.

   <dom> [35]https://github.com/w3c/mediacapture-fromelement/

     [35] https://github.com/w3c/mediacapture-fromelement/

   19 open issues, fairly old but heavy use.

   Need TAG/privacy/security review and check open bugs whether
   blocker or not

   media recorder API

   Need an editor and TAG review.


   scribe: spec: fairly active

   depth spec: no more progress, shipped in chromium under a pref.

   audio output devices: shipped in Chrome, Mozilla under a pref.

   scribe: in CR

   content hints: released in Chrome, works, WD

   DSCP: origin trial showed mixed results, especially in private

   WebRTC-SVC: active interest, early in development cycle

   WebRTC-ICE: Implemented in Chrome as part of QUIC experiment.
   Basic stuff working.

   No first WD yet.

   Other W3C activity: media wg activity is relevant to WebRTC WG

WebRTC 1.0 Testing

   Specs have links to tests, should allow to compute spec

   A lot of progress in tests passing in all 4 browsers.

   DrAlex presenting the WPT and KITE dashboards

   Simulcast testing big progress with IETF 104 and 105

Next steps to PR for WebRTC-pc

   Chrome has mid and rid header extensions, Firefox supports rid
   header extension.

   Florent implemented the simulcast playground for unified plan.

   Could be used as a basis for WPT.

   <scribe> ACTION: Florent to investigate upstreaming his page as
   WPT test

   <trackbot> Created ACTION-124 - Investigate upstreaming his
   page as wpt test [on Florent Castelli - due 2019-09-26].

   <dom> [36]Confluence-based WebRTC Implementation tracker

     [36] https://dontcallmedom.github.io/webrtc-impl-tracker/?webrtc

   Plan: do a final CR containing all new changes, then no
   substantive changes. Then validate testing is sufficient to go
   in PR.

   Goal is to go to PR by end of the year.

Issue 1764

   Bernard summarizing the issue

   Discussing Nils proposal.

   Harald: are all codecs ok with sending, then not sending and
   resending audio packets?

   Opus: you need to process a few packets before outputting sound

   Varun: what about doing like in mute case?

   Bernard: send silence is not very clear, might change according
   the negotiated parameters.

   RESOLUTION: Accept Nils proposal for Issue 1764

Issue 2121

   RESOLUTION: Proposal C: define retrieval of constraint
   properties for getSettings but make them not modifiable

   <jib> for width, height and frameRate, and aspectRatio

   Issue 2230

   <dom> trackbot, bye

   <dom> Youenn: the host field in the ice error event exposes
   private ip addresses

   <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

   <dom> ... the spec opens up the possibility to use if
   filtering is needed

   <dom> ... there is an odd case when you ask only for relay

   <dom> ... we could maybe filter the host address in that case

   <dom> ... returning instead of null is a bit strange

   <dom> ... and why is port and address in a single field?

   <dom> jan-ivar: maybe either than null, an empty string?

   <dom> harald: the advantage of is that it is
   parseable by an IP address parser

   <dom> ... e.g. if you log the errors

   <dom> dom: since it has been very recently deployed, this is
   purely a cosmetic design decision at this point

   <dom> jan-ivar: empty string sounds good to me

   <dom> henrik: we should be consistent with what we have in

   RESOLUTION: empty string for null value, split port separately

   <dom> (make port nullable, find name for host)

   <dom> ISSUE 2257

   Same certificate for workers so postMessage is potentially

   Bernard: for forking, same certificate for different endpoints,
   potentially in a worker thread.

   RESOLUTION: Keep the existing ability and put a note about the
   security issue.

   postMessaging a certificate might be useful in a data channel
   context so it might be a useful feature.

Screen capture

   Jan-Ivar is listing the list of improvements done in the past

   Issue 60: Define Tab Capture

   RESOLUTION: Use 'browsing context' as tab capture

   Need horizontal review, fill out privacy and security
   questionnaire. Need explainer.

   Discussion about tab capture. Mozilla might want to capture the
   active tab (without the other tabs like a window would leak).

   Potential clarification: make it clear that tab capture might
   change the the tab dynamically.

Media capture and streams

   Issue 554

   Harald: lack of spec actually makes it harder to implement.
   Definitely interested and would like to push implementation
   when there is a spec.

   Jan-Ivar: Would be good to have for our own testing.

   <dom> Issue 565

   RESOLUTION: allow browsers not to fire devicechange event if
   the list of device is actually the same

   <dom> make this mandatory behavior unless this can be

   Issue 584

   Safari has potential issues with downscale restriction in
   multiple apps accessing to camera.

   RESOLUTION: Remove upscale from the proposed sentence and merge

   Issue 608

Media Recording

   ISSUE 139

   Proposal is to always re-encode when mimeType is set and not
   reencode otherwise.

   RESOLUTION: Consensus for Proposal B

   Issue 167

   RESOLUTION: Start with proposal B, Jan-Ivar to create a PR,
   promise based.

   Need to discuss multiple track change cases.

WebRTC Stats

   <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

   <dom> ScribeNick: steveanton

   youenn: wpt should be enough for simple counters
   ... WebKit has some basic wpt validation that can be upstreamed

   hbos: chrome does not have detailed tests at the integration

   <dom> ACTION: Youenn to upload simple validation tests from
   webkit to WPT

   vr000m: explore simple tests in wpt then go forward from there

   bernard: new model better supports SVC

issues 361/452

   general agreement to proceed

issues 478/396

   youenn: can already get this information from the api

   jib: opposed for stats reporting things that the app already

   hbos: need mid to correlate stats objects with the m= section
   (proposal 2)

   jib: adding transceiver stats requires adding transceiver id

   bernard: snapshotting state would help correlate stats with
   changes in signaling

   jib: worried about bloat in stats objects

   vr000m: two issues (1) do we need a transceiver dictionary (2)
   once we have that do we need additional data e.g. direction

   jib: could also just put a mid on sender/receiver

   vr000m: stats are used largely for debugging

   agreement that mid should be mti

   jib: opposed to direction/currentDirection more than opposed to
   transceiver stats

   general agreement to add transceiver stats to with mid/sender
   id/receiver id only

   <vr000m> also codecIds?


   bernard and jib sold on proposal 1

   vr000m: like events since we then we don't have to shim

   youenn: prefer that stats expose replace track info directly
   rather than through events

   jib: see that shimming replacetrack is not ideal, but does work

   vr000m: not providing something like onstatsended leaves a gap
   with replacetrack that has been known for 2 years

   youenn: onreplacetrack should be a follow up and not in 1.0

   RESOLUTION: remove onstatsended and continue discussion about
   an event to notify when significant stats change


   RESOLUTION: consensus to remove track stats (moving it to
   obsolete section)




issue-28 & issue-30

   hta: more sympathetic to normative action than before

   hbos: agree that we should only ship APIs that are well defined

   jib: trying to be agnostic about what to do next, just want to
   provide feedback

   bernard: where to specify normative hints for content hints?

   jib/hta/bernard: content hints should be a follow up spec that
   covers the integrations with other specs

   youenn: is a high level api that influences control knobs the
   right design?
   ... if hints are crucial for an application then we should
   specify the behavior

   jib: hints can be useful since they are simpler than turning
   all the knobs

disposing of content-hint

   bernard: some advanced codecs have content capture tools (hevc,
   ... useful to expose this for e.g. screensharing

   RESOLUTION: advance but not at high priority


   RESOLUTION: proposal 1

   (Move Priority to DSCP document, harmonize, keep experimenting)


   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)

   dom: shouldn't be a high cost to the working group

   generally no opposition to adopting the spec

   bernard: do the p2p mesh folks want datachannels in workers?

   dom: does this expose new security & privacy risks?

   peter: need to think through the risks more

   bernard: forking has been thought through, but not in the
   context of p2p mesh
   ... who is asking for ICE forking? just dht people?

   hbos: why is ice forking hard?

   bernard: each transport has different candidate pair statuses,
   API changes (dtls transport) to facilitate forking, more ICE
   optimizations that are more important for forking
   ... might not be that complex if you started from scratch and
   knew what you wanted to do

   peter: two code bases which would need to implement forking

   no current plans for either to do it

   hta: not hearing much enthusiasm in the room

   jib: more use cases could motivate implementors

   bernard: p2p mesh is an issue in the use cases repo

Features at risk

   <dom> ScribeNick: dom

   JIB: Overview of feature at risks: there are about 12 features
   marked at risk
   ... I'll present some of our options to manage features at
   ... if no implementation and no dev interest, we remove the
   ... if no implementation but dev interest, we can leave the
   spec if we expect imminent implementation
   ... if not, we can move to an extension
   ... We conducted an analysis of what was implemented where to
   identify which features should be at risk
   ... focusing on things with fewer than 2 implementations and no
   clear implementation commitment
   ... for instance, rollback has only 1 implementation, but there
   is one ongoing
   ... [reviewing the list to check for possible mistakes]
   ... VoiceActivityDetection is at risk - only one (buggy)

   Bernard: does it negotiate CN?

   Henrik: checking it now

   JIB: OauthCredential is not implemented anywhere

   Henrik: re VoiceActivityDetection, what Chrome ships can be
   done via setParameters

   JIB: pranswer - 2 impl

   Youenn: not sure our implementation should really count; this
   may need to be marked at risk

   JIB: we're interested in implementing, but it hasn't been a
   ... QoS priority is at risk
   ... icecandidateerror?

   Henrik: it's shipped in Chrome and old-Edge

   Youenn: will need to be tested

   JIB: RTCError isn't shipped yet anywhere

   Henrik: we have the basic plumbing, but finalizing it is more
   work than you would expect

   Dom: how confident are we about this landing any time? any risk
   of later interop?

   Youenn: pages could break if they've started relying on
   existing error names
   ... Should we instead specify what currently ships (if

   Bernard: we designed RTCError to provide more details
   ... Errors in operational services occur at a very high rate

   Dom: let's plan on discussing this tomorrow

   JIB: simulcast-aware stats?

   Henrik: spec is ready

   JIB: commitment from Edge and Firefox to implement
   ... Are they MTI?

   Henrik: adopting them means changing the behavior in a
   backwards incompatible way

   JIB: statsended we decided to remove
   ... setStreams?

   Orphis: in Chrome

   Youenn: planned for us

   JIB: us too, by the end of the year
   ... RTCPeerConnectionIceEvent.url is only in Safari - any other
   implementation commitment?

   Bernard: I think we would want to do this for Edge/Chrome

   JIB: planned for us, but probably not by EOY
   ... Identity - in Stockholm, we reached a compromise to split
   identity into a separate spec
   ... there are still a few normative ref from -pc to -identity
   ... but still only one implementation
   ... are we ok with that situation?

   Youenn: I think it should be marked at risk

   JIB: getDefaultIceServices - not implemented should be marked
   at risk
   ... 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

   Youenn: Firefox and Chrome are the two main implementor for

   Armando: does the tests need an update?

   JIB: no, but implementations need to catch up with stats
   ... I don't think they should be in jeopardy because they moved
   ... Firefox doesn't have track-stats yet

   Dom: is the list of MTI stats in -pc correct?

   Henrik: it will have to be updated to match the results of our
   stats discussion tomorrow

   JIB: OAuthCredentials?

   RESOLUTION: move OAuthCredential to extension

   JIB: negotiate for rtcpTransport? (issue 3 in spec)

   Harald: impl got nuked, too confusing

   RESOLUTION: negotiate for rtcpTransport to be removed

   JIB: VoiceActivityDetection?

   Henrik: over taken by events, let's remove

   RESOLUTION: remove VoiceActivityDetection

   JIB: getDefaultIceServers()?

   Youenn: move to an extension and wait for a proponent to push
   for an improved proposal

   JIB: getSUpportedAlgorithms?

   RESOLUTION: remove getSupportedAlgorithms

   JIB: SendParameters.priority?

   Orphis: remove

   RESOLUTION: remove SendParameters.priority and prioritytype
   ... remove ReceiveParameters.encodings

   Orphis: (they're pointless)

   JIB: EncodingParameters.dtx?

   Bernard: nobody implements

   Orphis: available via SDP munging for OPUS in Chrome

   Harald: let's drop it

   Orphis: this applies to ptime and codecpayloadtype should also
   be at risk

   Henrik: a large discussion: there would be a need to control
   the codecs you sent beyond what to do with negotiation today

   Orphis: right now, it's read-only

   Henrik: codecpayloadtype could be removed and brought back
   later if there is demand in an extension

   Orphis: ptime isn't implemented, not clear demand

   RESOLUTION: Remove .dtx, .ptime, .codecpayloadtype from
   ... datachannel priority to be removed

   Dom: Identity - mozilla sole implementor?

   JIB: we want to see it adopted
   ... the peerIdentity steps could perhaps be moved to -identity

   Henrik: moving out is an editorial question
   ... but the real question is whether identity is part of 1.0

   Youenn: no plan to implement in 1.0; interested in the field,
   but not sure this is the right solution
   ... there may be other issues that need to be addressed with
   higher priority
   ... we don't want to be tied to that particular solution at
   this time

   RESOLUTION: migrate the remaining identity steps to -identity

   Dom: we also need to figure out how to re-integrate isolated
   media streams into our normative sphere

Developer feedback

   <inserted> ScribeNick: dontcallmeDOM

Mészáros Mihály’s Developer Feedback

   Mészáros: TURN for NRENs, Higher education & research.

   scribe: Global turn server, the goal is to keep media traffic
   in their network.
   ... Multi-tenant TURN is not possible without Long Term
   ... Working on co-located TURN, working on implementation in
   Firefox and possibly Chrome.
   ... Why not just add these three attributes, it would require
   little changes to mechanisms. Should be little effort.
   ... We should consider keeping OAuth until we have alternatives
   for TURN.

   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.

   Youenn: You say the existing API is not great, but is the
   current API working as a hack?

   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.

   Harald: Do any of the browsers implement the behave TURN REST?
   How do you do this with current implementations of browsers?

   Mészáros: It would be nice to have one authentication server

Sean’s Developer Feedback

   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.
   ... Small businesses want to use WebRTC but they have to use
   other things because they have restricted port ranges.
   ... 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.

   Jan-Ivar: The reason you can’t do addIceCandidate in a
   different order they could end up in the first offer.

   Sean: That’s only an issue for the first offer.

   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.

   Sean: In the real world this is a problem. People cache
   candidates for example. Jan-Ivar: You shouldn’t cache.
   ... Closing (message+code) can be done by sending a final
   ... Ability to deny a data channel based on data channel name.
   Not sure if enough value.
   ... Media via DataChannels is being more and more popular. Lack
   of HW acceleration.
   ... 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.
   ... People want setCodecPreferences; SDP munging is painful.
   I’m tired of seeing people munge SDP and it blows up in their
   ... Lack of CipherSuite choices: people want HW acceleration.
   ... addStream vs addTrack vs addTransceiver. Causes headaches,
   people don’t understand what’s going on.
   ... Provisional offers/answer: Do we need them? I have to
   answer questions about it all the time.
   ... Can we make API simpler for porting to other languages like
   not having to use strings?
   ... Tor Snowflake uses DataChannels and spend a lot of time
   removing the ability to fingerprint. Can we set ciphers?

Silvia’s Developer Feedback

   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.
   ... We have to recommend people not to use Firefox due to worse
   media quality. High-level report; don’t know why this is the
   ... We use the new API, using multiple streams works well in
   Chrome but not in Firefox. Interop problems.
   ... We sometimes hit decoding problems.
   ... 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.
   ... 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
   ... 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.

Emil’s Developer Feedback

   Emil: Will put in slides after the meeting. I have three items:
   ... 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.
   ... We keep hearing not all windows are sharable on windows.
   ... 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

   erent points in the pipeline to add our own logic.

“Others on the Line”: Max

   Max: Lack of granular port ranges.
   ... How do we add hooks on different parts of the stack. We are
   excited about these things becoming part of the standard and
   ... 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.

   Harald: Do you think we should revive SSRC signaling? Should we
   revive the draft that I wrote?

   Max: Yes. Loudly adding a plus one!

Summary of Action Items

   [NEW] ACTION: Florent to investigate upstreaming his page as
   WPT test
   [NEW] ACTION: Youenn to upload simple validation tests from
   webkit to WPT

Summary of Resolutions

    1. [37]Accept Nils proposal for Issue 1764
    2. [38]Proposal C: define retrieval of constraint properties
       for getSettings but make them not modifiable
    3. [39]empty string for null value, split port separately
    4. [40]Keep the existing ability and put a note about the
       security issue.
    5. [41]Use 'browsing context' as tab capture
    6. [42]allow browsers not to fire devicechange event if the
       list of device is actually the same
    7. [43]Remove upscale from the proposed sentence and merge
    8. [44]Consensus for Proposal B
    9. [45]Start with proposal B, Jan-Ivar to create a PR, promise
   10. [46]remove onstatsended and continue discussion about an
       event to notify when significant stats change
   11. [47]consensus to remove track stats (moving it to obsolete
   12. [48]advance but not at high priority
   13. [49]proposal 1
   14. [50]move OAuthCredential to extension
   15. [51]negotiate for rtcpTransport to be removed
   16. [52]remove VoiceActivityDetection
   17. [53]remove getSupportedAlgorithms
   18. [54]remove SendParameters.priority and prioritytype enum
   19. [55]Remove .dtx, .ptime, .codecpayloadtype from
   20. [56]migrate the remaining identity steps to -identity

   [End of minutes]



      [1] http://www.w3.org/

                         WebRTC TPAC F2F Day 2

20 Sep 2019


          Emad, Aramando, Henrik, Jan-Ivar, Bernard, Youenn,
          DrAlex, Orphis, Dom, Harald, EricC, weiler, tara,


          Harald, Bernard, Jan-Ivar

          hta1, hta, dom, dontcallmeDOM, dralex, dralex_,


     * [2]Topics
         1. [3]WebRTC-SVC
         2. [4]Privacy Issues
         3. [5]WebRTC NV Use Cases
         4. [6]Joint meeting with Accessible Platform Architecture
            Working Group
         5. [7]WebRTC stats
         6. [8]Issue 398/PR 495
         7. [9]issue-401
         8. [10]issue-443
         9. [11]issue-440
        10. [12]issue-448
        11. [13]issue-358
        12. [14]issue-376
        13. [15]issue-377
        14. [16]Content-Hints API
        15. [17]Conclusions and next steps
     * [18]Summary of Action Items
     * [19]Summary of Resolutions

   <hta1> scribenick: hta1


   Starting with SVC structures.

   Decision: Remove drawings from SVC spec; AV1 is normative for
   drawings. SVC spec is normative for strings; make that clear.

   Aboba - Presenting on custom scalability modes.

   If a different mode is required, we could define a new mode
   string. Assigning a new number in AV1 requires AOMedia

   aboba: we could define strings that reference AV1 custom
   scalability modes if we can define scalability structures using

   could also define modes in prose in this spec.

   <scribe> ACTION: aboba to Add a paragraph to the table to
   describe considerations for adding new values to the table of

   <scribe> "new modes can be added to this table by updating this

   issue 14 - orphis: Encoding parameters for spatial layers

   active, maxBitrate and maxFramerate probably make sense.

   <hta> youenn: what's the usecase for active?

   <hta> aboba: There's a difference between dropping a layer and
   changing a mode.

   <hta> amit: should we value consistency over conformance? Users
   will use modes that they dont understand, and will be

   <hta> hta: People who don't understand the codec and mode they
   are using are going to have a hard time anyway.

   <hta> orphis: <shows list of possible proposals>

   <hta> youenn: a mode would have a sensible default, used when
   you don't specify anything.

   <hta> scribenick:hta

   <scribe> scribenick: hta

   (discussing case of bitrate allocation - is percentage right,
   or is numbers right?)

   <weiler> where are minutes being taken?

   here. writing slowly.

   dr alex: scaleResolutionDownBy is independent for each layer in
   simulcast? several: yes, it is relationship to source, not
   between streams

   This discussion will continue at 2PM.

Privacy Issues

   <dontcallmeDOM> ScribeNick: dom

   <dontcallmeDOM> ScribeNick: dontcallmeDOM

   [welcoming PING representatives]

   Youenn: we want good privacy reviews on our planned Proposed
   Rec of WebRTC-PC and Media Capture
   ... Issue 612
   ... enumerateDevices is a way for Web pages to enumerate all
   capture devices (camera, mics, speakers)
   ... it's meant to help implement a device picker to select a
   particular camera and microphone
   ... that information is gated by device-info permission
   ... without that permission, you don't get labels, but you get
   persistent device ids and that entails the exact number and
   type of devices
   ... our proposal is to hide more info before device-info is
   granted, only expose generic/low-fingerprint profile of devices
   ... In Safari, we've looked at Web pages - most device pickers
   are only available after getUmserMedia was granted
   ... one proposal was to expose one device of each type - that's
   what Safari ships; it is Web compatible
   ... (we haven't received negative feedback since we've shipped
   this a month ago)
   ... this still exposes whether a given device has access to a
   capture device of given type
   ... A second proposal is to lie: pretend there is one capture
   device of each given type
   ... you get the truth after the gUM prompt
   ... this fixes the fingerprinting issue of the 1st proposal
   ... a 3rd proposal would be to push enumerateDevices() behind a
   ... but that feels difficult to implement (how to make it
   meaningful to the user)
   ... also feels hard from a compat perspective

   PeterSnyder: is this actually used for fingerprinting?

   Youenn: yes

   EricC: and it is used for that a lot more than for getting

   Harald: hangout chat will display a camera icon only if it
   finds a camera in its chat mode
   ... proposal 2 would make that distinction useless

   Youenn: this would require a change in the UX of hangout

   Sam: what is the deviceId? free-form string?

   Youenn: a UUID

   JIB: per-origin

   Youenn: double-keyed

   Dom: what if new capture device types come in?

   Harald: e.g. depth cameras which are in the pipeline

   Youenn: I think this would have to move to a picker-based

   Armando: lying about devices availability doesn't sound right

   EricC: in Safari, we default to the list of capture devices
   that are tied to that platform (e.g. 2 cams, 1 mic on iPhones)
   ... if there are additional devices, we pretend they come up
   upon gUM grant

   PeterSnyder: would moving to Proposal 3 in the long term be a

   EricC: what kind of questions would make sense for Option 3?

   Sam: one anti-pattern is asking permissions as soon as users
   get in
   ... I've been that in WebRTC land in particular when it comes
   to asking for cameras

   <weiler> axk wei

   Bernard: part of the reason this happens is because fewer and
   fewer features are available before you ask for permissions
   ... e.g. network topology detection is gated to camera
   permission today
   ... and as this causes problems to real deployment

   JIB: I doubt going to permission prompt is a direction any
   browser would go to
   ... plus, a permission prompt for enumerating devices would be
   just before another prompt

   Harald: I'm hearing moving towoard Proposal 1 would be
   acceptable to all implementors

   <hta> we have 5 issues to get through. We have 45 minutes.

   <hta> (now we have 22 minutes)

   Harald: Proposal 2 is more controversial

   PeterSnyder: I do have concerns with proposal 1

   Dom: for clarity, all these proposals are improvements over the
   current situation

   PeterSnyder: Proposal 2 then lies about the reality? when does
   the truth get revealed?

   EricC: upon getting permission access for capture
   ... the list of devices would be updated (with an event) to
   reflect the reality

   PeterSnyder: OK, that sounds appealing

   Youenn: Proposal 1 is clearly implementable (shipped in Safari)
   ... Proposal 2 will break some web sites e.g. if they adapt
   their default UI to what's available
   ... hearing Proposal 1 is a good implementors target in the
   short term; Proposal 2 is appealing to PING
   ... and appealing to some implementors
   ... Issue 607 - persistence of device ids
   ... can be used for cross-site tracking
   ... deviceIds have already some level of protection
   ... they're not exposed to cross-origin iframes
   ... they can also be hidden from iframes with device-info
   ... A proposal is to partition id if other persistent partition
   ... Difficult in making it mandatory today given existing
   ... Re partitioning, Safari double-keys all persistent data
   based on the nesting of browsing context (à la iframe) origins
   ... (existing discussions in this space for http cache in fetch
   spec, and in service workers)

   <Orphis> Double keyed HTTP cache:

     [20] https://github.com/whatwg/fetch/issues/904

   PeterSnyder: the concern is when there is no double-keying

   Youenn: the goal is to go there; the question is what to do
   when double-keying is not available

   PeterSnyder: I'm suggesting double-keying the seeding of UUID
   ... to partition the deviceId space

   JIB: this breaks the case of embedded e.g. Hangout
   ... and it doesn't actually buy privacy until indexeddb is

   PeterSnyder: PING would be happy with requiring partitioning of

   Youenn: Issue 374
   ... WebRTC Stats is exposing for network types from users
   ... e.g. if the user is on wifi, ethernet, vpn, etc
   ... mostly for debugging purposes
   ... the problem is that it exposes fingerprinting surface,
   expose privacy-sensitive information
   ... and could be mis-used for user-hostile adaptation
   ... A first proposal would be to move this to an extension spec
   where special mitigations could be discussed
   ... Second: we have already a note about this, nothing needs to
   be done
   ... Third: we hide this behind the getUserMedia

   Emad: what's the fingerprinting surface?

   Youenn: you can monitor the different types of network a user
   has been using, when, detect patterns

   @@@: different behavior on different type of networks sounds

   Dom: not what WebRTC Stats are meant for - they're meant for
   monitoring or debugging

   <hta> Amit = amit

   Dom: UX adaption would need to use e.G. network information

   <weiler> debugging should be "special case", right? hence it's
   okay to not provide the info in the ordinary case?

   Peter: Network Error Logging is another API that reports
   information on network traffic

   Dom: does it?

   Peter: would need to double check

   Harald: Proposal A & B doesn't actually change what's shipping
   ... C about guidance feels more important

   Dom: let's distinguish between the practical considerations of
   where to define the mitigations
   ... I think I'm hearing interest in investigating mitigations
   in more details

   Amit: we could fuzz the network types (e.g. network1, network2,
   ... could help distinguishing cases of debugs

   Peter: I think that rather guidance is specific rules

   Bernard: in practice, vpn isn't all that useful

   Christine: vpn are actually forbidden in some countries, this
   shouldn't be broadcasted

   Harald: vpn should just be deleted from what I'm hearing
   ... we still need to look at how critical networkType is for
   debugging purposes given the concerns we're hearing

   Henrik: other exposed stats given maybe more actionable (e.g.

   Dom: proposal D would then be removing it

   <weiler> again, isn't debugging a special case, such that it
   could be hidden behnd a permission?

   Peter: PING would support removing it if that's not too big a
   loss, gating it would be the fallback

   <Amit> we might want qingsi to give an opinion as an expert on
   ice debugging

   Youenn: Issue 83 in audio output
   ... We're currently limited to which speakers can be used for
   audio output
   ... as it linked to getting permission to getting audio input
   ... We would like to offer an in-chrome picket to give access
   to new devices

   Armando: we're supportive

   Peter: without knowing the details, this sounds interesting

   Youenn: thank you for all your help

   Peter: thank you for having us

WebRTC NV Use Cases

   <scribe> ScribeNick: dralex

   <dontcallmeDOM> ScribeNick: dralex_


   14 open issues

   ++> issues 53

   advanced codec cap.

   HW acc available?

   min and max resolutions

   support for sic ?


   use case B : identify the implementation (good for debugging,
   and good for adaptation to a specific implementation features)

   in some cases, supported profiles and resolutions are different
   for HW and software

   right now the encoder is assigned during negotiation, and then
   the bandwidth adaptation might change the setting outside of
   what the current encoder/decoder can do.

   youenn express concerns that from the developer point of view,
   it can become real hard to handle.

   Action item, henrik will ....

   describe one or two uses cases, and then make a PR.

   JY: it seems to be presented the wrong wa: API first, instead
   of use case first. Can you please write the use corresponding
   use case?

   florent: we would like to be in a case where we get helpful
   error messages to act on it.

   dom: that really underline the need to write a user story

   JY: we have to be careful not to augment the fingerprinting


   issue 37: requirement for secure web conferencing.

   second attempt since the meeting in Stockholm

   PR 49 submitted by Cullen

   google'se mad suggested that we look at the MLS security
   architecture as an inspiration to write our requirements here

   discussion about req. N25 to N29 from MLS

   proposal to put that in the secure conferencing requirements

   dom recommandatie is to only fuse one of this use case.

   mozilla position is to merge in the untrusted case, and needs
   to think about the trusted case.

   google is considering very seriously considering the trusted
   case and implementing it

   apple is not in favour of anything, but shows interest in the
   result of investigations from mozilla and google.


   charte expire in march 2020

   since a new or updated charter would need 3 months to be
   approved, we would need a WG-approved draft by EoY

   obvious charter changes:

   2 secs out (webrtc 1.0, GUM)

   update deliverable timelines

   <dralex> scribbing

   <dralex> open questions: what do we do with existing

   <dralex> is there any new deliverable?

   <dralex> how long do we need.

   <dralex> what should we do about the maintenance of webrtc 1.0
   and GUM

   <dralex> what about webrtc-stats and webrtc identity

   <dralex> there is also a leak of editor

   <dralex> some people and/or organization need to provide

   <dralex> other specs are stable but much earlier in the
   standardisation process.

   <dralex> image capture, depth cameras

   <dralex> content hints

   work could only continue with an identified editor, AND a
   commitment by a browser vendor to implement

   emerging use cases

   more granular objects

   webrtc insertable

   end-to-end encryption

   <dralex__> really only three ways forward:

   <dralex__> in re-chartered group: only with editor and
   implementor commitment

   <dralex__> in incubation (CG group)

   <dralex__> or moved to another group (media group)

   <dralex__> it seems that the consensus is to keep the 3
   activities together (maintenance, dev, ....)

   <dralex__> the question is open about whether some media
   capture should follow web transport, webcodec.

   <dralex__> the consensus seems that there is a strong link with
   web transport and webcoedc (peter), but as it would dbe the
   same implementor as the main webrtc spec, it would make sense
   to keep things together

   <dralex__> interest from mozilla and apple on image capture

   <dralex__> no strong interest in depth

   <dralex__> stop discussion here because of time questions

Joint Meeting with Accessible Platform Architecture Working Group

   [21]Minutes taken in APA meeting minutes

     [21] https://www.w3.org/2019/09/20-apa-minutes.html#item02

   <jcraig> Web RTC group. Dom said to come to the #APA room (the
   physical room) in Kashi 1F right behind registration

   <dom__> [minutes for this meeting taken on #apa]

   <vr000m> trying to join the meeting URL is this URL correct:

     [22] https://meet.google.com/vxf-wgai-rjn

   <hta> we're having a meeting in a different room at the moment,
   so I guess nobody's watching the "allow to join" button.

   <hta> will be back soon.

   <vr000m> ok

   <dontcallmeDOM> scribenick: steveanton

WebRTC stats

   RESOLUTION: issue-365 & issue-470: just remove
   RTCMediaStreamStats (move to obsolete)
   ... issue-437: agreement for proposal

Issue 398/PR 495

   jib: like these members better than those proposed for
   transceiver stats

   hbos: already have per-encoding stats in the outbound-rtp
   stats, only thing missing is the rid
   ... if that's the only thing we want we should just add it to
   ... but if we want more information then we should have a
   separate dictionary

   jib: prefer to just add rid to outbound-rtp

   vr000m: if getParameters exists then rid should be sufficient
   ... no concrete objection to just adding rid but would prefer
   consulting with the list to see if the other stats are useful

   jib: might be a bug in getParameters -- every time you call it
   transaction id changes
   ... which means you don't know if the transaction id changes
   because of getParameters or an outside change

   dom: let's discuss that in a separate issue

   RESOLUTION: add rid and confirm that we don't want to add
   encoding parameters


   bernard: along with svc we have a new weird thing of simulcast
   without different rtp streams
   ... when talking about layer we should identify the layer and
   the mode of the layer

   hbos: might just have an index into the svc config array

   bernard: need temporal id & spatial id to identify a layer.
   byte for each would work for every known codec

   vr000m: are sid's numbers?

   bernard: possible to have sid represent a simulcast encoding
   ... could have multiple simulcast encodings in the same rtp
   ... need to describe better what the layer is and what mode it

   vr000m: we should discuss this in another meeting since it's
   getting complicated
   ... can the svc mode change?

   bernard: yes, and would affect the number of layers and stats

   hbos: does the basic idea of having one svc stats object per
   layer with these attributes make sense?

   bernard: definitely want to know aggregate stats for the entire
   ... not sure if per-layer loss is useful for congestion control
   ... might use the stats to realize after the fact that your
   behavior was sub-optimal

   hta: framesSent and bytesSent seem like enough

   jib: inconsistency ... width vs. frameWidth

   hbos: because in that dictionary there's a mix of audio and
   ... frame was added to make it clear it's for video

   RESOLUTION: henrik should go write a PR and we'll add it


   vr000m: isn't the endpoint aware of the deviation of the stats
   from expectation?

   hbos: need to define expectations

   vr000m: can do the math. expectation is inter-frame stats

   hbos: over what time frame?

   alex: expectation changes with sfu

   hbos: expectation can change during call (60 fps to 30 fps)
   ... shouldn't be reported a glitch

   alex: can only define a glitch by knowing what was sent by the

   hta: calculate the sum of intervals and sum of squares of
   intervals? allows you to calculate mean and std dev

   jib: before or after the jitter buffer?
   ... on the sender side there's feature creep
   ... where we have stats on the sources
   ... worried we are adding stats for playback

   hbos: this has to do with received
   ... but will be visible in playback
   ... don't intend to measure how the video tag works

   alex: need to decouple which part of the video playback
   pipeline is being measured

   jib: if we have a stat that reports glitches but don't have any
   rendering glitches because jitter buffer smoothed it over is

   alex: don't want to force the app to query stats too often

   hbos: need to be specific with how glitch is defined
   ... getting the feeling we should move towards proposal B

   jib: why do we care about glitches before jitter buffer?

   hbos: only care about after jitter buffer
   ... some existing stats are confusing about this though

   varun: want the stat for after the jitter buffer

   alex: fps is supposed to be stable by segment
   ... there will be a step at some point
   ... can we report the stability of fps within segments?

   hbos: that would show up as a glitch in proposal B

   alex: can infer expectation by assuming fps is constant for a
   period of time

   hta: sum of square intervals allows you to calculate the
   average/std dev of arrival rate between any two samples

   hbos: that sounds like it would solve the problem

   RESOLUTION: add a stat which is the sum of the square of inter
   frame intervals


   hbos: implementation has separate booleans but they are not

   alex: but this isn't implementation specific

   armax: proposal C: remove?

   hbos: chrome reports cpu over bandwidth if both are true

   discussion about what is the use case for this stat

   varun: cpu limiting is interesting when it happens
   ... bandwidth limiting we have a lot of other stats
   ... cpu is influenced by unknown things on the system

   hbos: issue is not about having this stat but what to do when
   both value apply

   jib: if the value is none you can infer that quality is fine

   hbos: any value other than none indicates you are not sending
   the resolution you want

   jib: this is sender side only?

   hbos: yes

   varun: none can also be source limited
   ... e.g. if the camera can't capture enough pixels because it's

   jib: can add the string both

   hbos: didn't want to add a vector since you might infer that a
   false element indicates no problem
   ... e.g. if you are so cpu limited that you can't use all your

   jib: if there's a situation where both are limiting, can you
   improve quality by improving either or both?

   hbos: likely limited by both

   varun: other implementations may know what is the real limiting
   ... so proposal b seems better

   hbos: should we say that if the implementation can't
   distinguish just say bandwidth?


   RESOLUTION: go with the proposed solution


   jib: what would happen after an ice restart finishes?
   ... when do the stats go away?

   hbos: they go away automatically with no event

   jib: changing the id would mean they are not referenced
   ... so you can infer they are no longer in use

   hbos: they would not exist in that case

   jib: what if you are in the middle of an ice restart?

   varun: depends on behavior of make before break
   ... e.g. if you are still using the transport
   ... you would see both objects

   jib: how would you know what is the old or new one if both are

   hta: we should do proposal a

   hbos: proposals are not mutually exclusive

   RESOLUTION: go with proposal a and continue discussing proposal


   steveanton: problem is this is an instantaneous stat not a
   cumulative stat

   hbos: can't think of a good cumulative stat

   steveanton: could do minimum rtt

   hta: building on a standard stat that is part of the protocol
   machine is ok

   hbos: continue looking for a cumulative stat we could use

   RESOLUTION: try to find a cumulative stat that could be used
   for rtt, but otherwise rely on spinfo_srtt -- regardless we
   want sctp rtt


   hta: cwindow is orthogonal to bufferedAmount

   steveanton: cwindow is useful for application logic, but
   getstats is not a good place to put it

   RESOLUTION: don't add to stats but discuss adding a dedicated
   API (not in 1.0)

   <dontcallmeDOM> scribenick: dontcallmeDOM

Content-Hints API

   Harald: Recalling previous discussions, words that could
   characterize the contents of a track. Close discussion by
   Harald rewriting draft based on ideas presented at the meeting,
   including MUST/SHOULD.

   Jan-Ivar: And clarify track.clone().

   Harald: Need to specify that it copies all the attributes.

   Jan-Ivar: And add guidance for future specs.


   [Armando was able to name the bird.]

Conclusions and next steps

   Harald: We have a number of PRs to write now. We have a number
   of documents that need wider review, including TAG. Shepherding
   needed. We have gone through features at risk; the proposal is
   to delete all features marked in the document, except for
   maxFramerate and RTCError.

   Youenn: RTCError needs more discussion? It should be marked
   feature at risk but let’s not delete it for now.

   Bernard: PR requirement is to have better error handling, so
   removing it from the spec might create more work than it saves.
   It needs more discussion.

   Harald: Move the normative identity dependency steps to the
   extension spec.

   Youenn: E.g. call a NO-OP function or step that is overridden
   by the extension spec.

   Bernard: Isolation...?

   Jan-Ivar: Both webrtc-pc and media recorder has language like
   MUST NOT record if there are isolated properties. We can move
   this out of identity to mediacapture-main.

   Youenn: It should stay in the identity spec for now because it
   is a feature at risk.

   Harald: Action item on Jan-Ivar to sort out isolation property
   (suggesting to move it?).

   Youenn: Let’s do ICE forking later on as an extension spec or
   iterative work.

   Harald: Developer feedback; people still not happy with Unified
   Plan switch and consistency. More SSRC nosies.
   ... SVC, keep it simple please. We only support predefined
   ... Privacy issues. Details in the minutes.

   Youenn: Now is the time for PRs.

   Harald: We did not get to issue 68.

   Youenn: Don’t know what to do about that, need to pick up
   discussions and figure out what to do there.

   Harald: NV use cases. Split conferencing PR in two, Jan-Ivar
   will go back to Firefox to clarify if we can merge the
   untrusted JavaScript case. We should want this, but there is
   disagreement if we should support trusted JavaScript use case.
   ... Rechartering. Not too much to say about that. Discussed
   options, no clear answer. Should we incubate specs? WIll
   discuss further.
   ... Stats again. And then we ran out of time.

Summary of Action Items

   [NEW] ACTION: aboba to Add a paragraph to the table to describe
   considerations for adding new values to the table of modes.

Summary of Resolutions

    1. [23]issue-365 & issue-470: just remove RTCMediaStreamStats
       (move to obsolete)
    2. [24]add rid and confirm that we don't want to add encoding
    3. [25]henrik should go write a PR and we'll add it
    4. [26]add a stat which is the sum of the square of inter
       frame intervals
    5. [27]go with the proposed solution
    6. [28]go with proposal a and continue discussing proposal b
    7. [29]try to find a cumulative stat that could be used for
       rtt, but otherwise rely on spinfo_srtt -- regardless we
       want sctp rtt
    8. [30]don't add to stats but discuss adding a dedicated API
       (not in 1.0)

   [End of minutes]

Received on Monday, 23 September 2019 12:49:57 UTC