[minutes] March 24 meeting

Hi,

The minutes of our WG meeting last Tuesday are available (with video 
recording) at https://www.w3.org/2026/03/24-webrtc-minutes.html and 
copied as text below.

Dom

                        WebRTC March 2026 meeting

24 March 2026

    [2]Agenda. [3]IRC log.

       [2] https://www.w3.org/2011/04/webrtc/wiki/March_24_2026
       [3] https://www.w3.org/2026/03/24-webrtc-irc

Attendees

    Present
           BartoszHabrajski, caribou, Dom, Guido, Harald, Jan-Ivar,
           KacperWasniowski, PeterT, SunShin, ThomasNGuyen, TimP,
           Youenn

    Regrets
           -

    Chair
           guido, jan-ivar, youenn

    Scribe
           dom

Contents

     1. [4]WebRTC-PC Interop Issues
          1. [5]Issue #3088 [[IceRole]] initialized too late
          2. [6]Issue #3090 · Should garbage collecting
             RTCPeerConnection be observable?
          3. [7]Issue #3092 · RTCError should be exposed on Workers
          4. [8]Issue #3095 · https://w3c.github.io/
             webrtc-pc/#dfn-final-steps-to-create-an-offer is
             unclear
          5. [9]Issue #3096 · Vague error for setting a
             description, inconsistent wpt
          6. [10]Issue #3097 · Should RTCDataChannel.send be
             allowed to throw synchronously for not enough buffer
             space
     2. [11]Capabilities Element
     3. [12]MSTP audio / AudioTrackGenerator
     4. [13]Summary of resolutions

Meeting minutes

    Recording: [14]https://www.youtube.com/watch?v=TilVQOs8WPY

      [14] https://www.youtube.com/watch?v=TilVQOs8WPY

    IFRAME:
    [15]https://www.youtube.com/embed/TilVQOs8WPY?enablejsapi=1&rel
    =0&modestbranding=1

      [15] 
https://www.youtube.com/embed/TilVQOs8WPY?enablejsapi=1&rel=0&modestbranding=1

    Slideset: [16]https://docs.google.com/presentation/d/
    1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/ ([17]archived PDF
    copy)

      [16] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/

   [18]WebRTC-PC Interop Issues [19]🎞︎

      [18] https://github.com/w3c/webrtc-pc/issues/
      [19] https://www.youtube.com/watch?v=TilVQOs8WPY#t=205

    [20][Slide 10]

      [20] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#10

     Issue [21]#3088 [[IceRole]] initialized too late [22]🎞︎

      [21] https://github.com/w3c/webrtc-pc/issues/3088
      [22] https://www.youtube.com/watch?v=TilVQOs8WPY#t=217

    [23][Slide 11]

      [23] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#11

    [24][Slide 12]

      [24] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#12

    [25][Slide 13]

      [25] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#13

    Youenn: any observable change from this?

    Jan-Ivar: I don't think so, but still to be confirmed through
    updated WPTs

    RESOLUTION: Proceed with PR to fix this

    Guido: the PR may provide opportunity for more detailed
    reaction

     Issue [26]#3090 · Should garbage collecting RTCPeerConnection be
     observable? [27]🎞︎

      [26] https://github.com/w3c/webrtc-pc/issues/3090
      [27] https://www.youtube.com/watch?v=TilVQOs8WPY#t=458

    [28][Slide 14]

      [28] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#14

    Youenn: when eventhandlers are registered, the PC isn't GC-able
    … pc.onicecandidate is registered in the test under discussion

    Harald: I'm remembering updating tests to add pc.close() to
    ensure GC
    … we've been pushing that any way of reaching an open PC should
    make it not GC-able

    Jan-Ivar: GC is obversable from the remote end
    … current Firefox behavior is to GC more aggresively than other
    browsers, which avoids issues when devs don't call pc.close()

    Youenn: in the test case we're discussing, this is because FF
    detects no ice candidate can reach pc2? otherwise, it feels
    like a bug in FF

    Youenn: not sure about changing the spec; the test probably
    needs more review

    Dom: how much real-word compat issue is this creating?

    Jan-Ivar: not aware of any specifically

    Dom: then maybe we don't need to fix it

    Harald: fixing the test feels like always worth it

     Issue [29]#3092 · RTCError should be exposed on Workers [30]🎞︎

      [29] https://github.com/w3c/webrtc-pc/issues/3092
      [30] https://www.youtube.com/watch?v=TilVQOs8WPY#t=1335

    [31][Slide 15]

      [31] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#15

    RESOLUTION: adopt proposal

     Issue [32]#3095 · [33]https://w3c.github.io/
     webrtc-pc/#dfn-final-steps-to-create-an-offer is unclear [34]🎞︎

      [32] https://github.com/w3c/webrtc-pc/issues/3095
      [33] 
https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-offer
      [34] https://www.youtube.com/watch?v=TilVQOs8WPY#t=1408

    [35][Slide 16]

      [35] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#16

    [36][Slide 17]

      [36] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#17

    Jan-Ivar: another option is to clarify the intent of the spec

    Youenn: that's option A

    Jan-Ivar: this predates promises, when we had concerns about
    the negotiationneeded event
    … this may no longer be as much an issue if you await promises,
    but there are still hard-to-pin-down tricky timing issues that
    this was meant to prevent and are likely still relevant
    … FF optimizes this cleverly, which could serve as a basis for
    a more specific algorithm
    … the main goal is to ensure that as you're about to send the
    results of createOffer, you ensure it's still aligned with JS
    state

    Youenn: given the example is about system resoures, that's not
    so clear to me

    Harald: the relevant test creates an offer without any tracks,
    then add a track; this is not obvious that this is what the
    spec is asking
    … I'd be in favor of some version of Option A if we can find a
    clean way to spec it

    Youenn: if we go with option A, if negotiation might be needed
    and createOffer is in process, you would need to check
    … the spec already asks to generate the answer on main thread
    … we should either clarify the spec with normative language, or
    non-normative language, to ensure alignment between what's the
    page is asking and the offer

    PROPOSED: Proceed with option A, ideally with normative
    language, or non-normative if not possible

    Guido: is this causing issues in the wild? if not, option C is
    good

    Youenn: not aware of real web compat issues

    Jan-Ivar: can't rule it out since they would be really hard to
    track down

    Harald: let's see a concrete proposal for option A before
    resolving this

    TimP: if the change you've put in JS is not in the offer, won't
    there be a negotiationneeded event to fix things?

    Jan-Ivar: but using negotiationneeded isn't required

    TimP: if this was designed before we added better APIs
    (negotiationneeded and transceiver), is this complexity still
    needed?

    Jan-Ivar: there are data races that the spec should protect
    from, even if they're corner cases

    youenn: it's not an alternative between race and no-race - it's
    mostly about optimizing API shape

    Jan-Ivar: I'll provide more background on the historical intent

     Issue [37]#3096 · Vague error for setting a description,
     inconsistent wpt [38]🎞︎

      [37] https://github.com/w3c/webrtc-pc/issues/3096
      [38] https://www.youtube.com/watch?v=TilVQOs8WPY#t=3194

    [39][Slide 18]

      [39] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#18

    [40][Slide 19]

      [40] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#19

    [41][Slide 20]

      [41] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#20

    Guido: does this mean Chrome and Safari would fail the test?

    Jan-Ivar: yes

    Harald: I agree with the principle

    Guido: I'm OK with fixing the test, but wouldn't want to keep
    it in Interop 26

    Youenn: I'm OK with the fix; no strong feeling about interop
    26, doesn't look like it should be a big change to libwebrtc

    RESOLUTION: Proceed with fixing test case; integration in
    interop 26 still TBD

     Issue [42]#3097 · Should RTCDataChannel.send be allowed to throw
     synchronously for not enough buffer space [43]🎞︎

      [42] https://github.com/w3c/webrtc-pc/issues/3097
      [43] https://www.youtube.com/watch?v=TilVQOs8WPY#t=3689

    [44][Slide 21]

      [44] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#21

    [45][Slide 22]

      [45] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#22

    Jan-Ivar: FF lets you send an unlimited amout since we didn't
    see a reason to limit it; the proposed change works for us,
    although UA-dependent behavior isn't great

    Youenn: this may be something worth bringing in a separate
    issue, but not part of interop 26

    RESOLUTION: Proceed with proposal of spec clarification

   Capabilities Element [46]🎞︎

      [46] https://www.youtube.com/watch?v=TilVQOs8WPY#t=4107

    [47][Slide 25]

      [47] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#25

    Daniel: we've been discussing the <usermedia> element, now I
    have a draft spec
    … interested in guidance in how to proceed with it moving
    forward
    … we have a chrome legacy attribute on which I'm also seeking
    guidance

    Jan-Ivar: going piecemeal would be OK

    Youenn: +1 with going piecemeal after initial explainer - you
    may need to update mediacapture-main with hooks

    Daniel: should I model this after the other explainer in
    mediacapture-extensions?

    Guido: start from the TAG model

    [48]Explainer Explainer

      [48] https://w3ctag.github.io/explainer-explainer/

    Youenn: so start with an explainer, then a series of PR on
    media capture extensions (possibly completed with additions to
    -main as needed)
    … do you have a sense of a timeline?

    Daniel: hope to get back to this next week; we already have a
    Blink-process explainer which I hope can serve as a good basis

   MSTP audio / AudioTrackGenerator [49]🎞︎

      [49] https://www.youtube.com/watch?v=TilVQOs8WPY#t=4439

    [50][Slide 28]

      [50] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#28

    [51][Slide 29]

      [51] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#29

    [52][Slide 30]

      [52] 
https://docs.google.com/presentation/d/1ECkxmWxXJFK_mv14UHcLiDmO6KczaHQhTVlE69lAqEs/#30

    Jan-Ivar: the data has been longer to produce than initially
    planned given Paul's availability

    TimP: I have some sympathy on the overlap argument, but the use
    cases are quite different
    … MSTP is mostly useful when you're processing both audio and
    video together - having different APIs for things that are
    tightly coupled in the way developers approach it is not very
    satisfactory
    … e.g. do lips-rerendering in video based on the audio

    Jan-Ivar: our finding is that audio and video are different
    enough that you're likely to end up wanting to treat them
    differently

    TimP: I still feel like there is a useful niche in approaching
    them together

    Guido: beyond measurements (on which I'm looking forward to
    refutal) - there is a non-niche use case requested by multiple
    use cases we presented at a previous meeting where audio
    glitches feel unavoidable when processing doesn't hit audio
    deadlines
    … this particular use case can't be implemented without
    glitches in FF and Safari given lack of MSTP audio

    Jan-Ivar: might be worth highlighting it on the github issue

    Youenn: TimP made a good point about the scenario where having
    main thread + audio worklet + worker - this would be what a
    test should demonstrate
    … it would be good to ensure the requirements from Chrome's
    team are well understood

    Guido: we have sample code that illustrated our use case

    Youenn: so two actions are needed: a better MSTP shim, and an
    illustration of how to avoid glitches when audio processing
    can't meet the audio clock based on the sample Guido shared
    previously

    Harald: I would encourage a dedicated meeting between Guido and
    Paul to advance on this outside of a WG meeting

    [53]Previous discussion on the topic

      [53] https://www.w3.org/2025/12/09-webrtc-minutes.html#97b7

    Jan-Ivar: to clarify, the goal of the shim is not to
    demonstrate no perf impact - the proper comparison should be
    with a audio worklet architecture

    TimP: if there is a such meeting, hope the group is invited
    (even if not required)

    @@@: if there are differences of jitter between input and
    rendering, there will be glitches if there is no buffering,
    given WebAudio and MSTP have different models (push vs pull)

    Youenn: what timeline for these actions? given potential
    dependency on implementation work

    Jan-Ivar: I need to check with Paul

Summary of resolutions

     1. [54]Proceed with PR to fix this
     2. [55]adopt proposal
     3. [56]Proceed with fixing test case; integration in interop
        26 still TBD
     4. [57]Proceed with proposal of spec clarification

Received on Friday, 27 March 2026 08:56:06 UTC