[minutes] July 2022 meeting

Hi,

The minutes of our meeting yesterday (July 19) are available at:
   https://www.w3.org/2022/07/19-webrtc-minutes.html

and copied as text below.

The video recording might take a while to be published due to Summer 
absences.

Dom

                         WebRTC July 2022 meeting

19 July 2022

    [2]Agenda. [3]IRC log.

       [2] https://www.w3.org/2011/04/webrtc/wiki/Main_Page
       [3] https://www.w3.org/2022/07/19-webrtc-irc

Attendees

    Present
           Bernard, Carine, Dom, Florent, Jan-Ivar, Philipp, TimP

    Regrets
           Elad, Harald

    Chair
           Bernard, Jan-Ivar

    Scribe
           dom

Contents

     1. [4]WebRTC Extensions
          1. [5]Add SCTP rate control params to RTCPeerConnection
             constructor
          2. [6]Issue 107: maxFramerate probably should not be
             allowed in addTransceiver/setParameters for audio
             senders
          3. [7]Issue 110: getDataChannels() method on
             RTCPeerConnection
     2. [8]WebRTC
          1. [9]Issue 2735: webrtc-pc specifies using ‘~’ in
             a=simulcast, but does not support RFC 7728 (RTP pause)
          2. [10]#2746: Enum RTCIceCredentialType with only one
             value
          3. [11]Issue [12]#2743: SLD/SRD (answer) trips over
             itself when narrowing simulcast envelope
          4. [13]#2751 Intended outcome when modifying direction in
             have-local-offer
     3. [14]WebRTC Simulcast issues
          1. [15]Issue [16]#2722: sRD(offer) completely overwrites
             pre-existing transceiver.[[Sender]].[[SendEncodings]]
          2. [17]Issue [18]#2724: The language around setting a
             description appears to prohibit renegotiation of RIDs
          3. [19]#2722
          4. [20]Issue [21]#2723: The prose around "simulcast
             envelope" falsely implies that simulcast encodings can
             never be removed
     4. [22]TPAC
     5. [23]Summary of resolutions

      [10] https://github.com/w3c/webrtc-pc/issues/2746
      [12] https://github.com/w3c/webrtc-pc/issues/2743
      [13] https://github.com/w3c/webrtc-pc/issues/2751
      [16] https://github.com/w3c/webrtc-pc/issues/2722
      [18] https://github.com/w3c/webrtc-pc/issues/2724
      [19] https://github.com/w3c/webrtc-pc/issues/2722
      [21] https://github.com/w3c/webrtc-pc/issues/2723

Meeting minutes

    Slideset: [24]https://lists.w3.org/Archives/Public/www-archive/
    2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf

      [24] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf

   WebRTC Extensions

     [25]Add SCTP rate control params to RTCPeerConnection constructor

      [25] https://github.com/w3c/webrtc-extensions/issues/71

    [26][Slide 11]

      [26] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=11

    Bernard: filed by someone writing a terminal app - would apply
    to a PC in the cloud
    … problems with exponential RTO backoffs
    … can we give developer control to these values which are
    tricky to get right?
    … typically apps would use unreliable unordered transport and
    deal with this themselves
    … not clear we need to allow this. any objection to "won't
    fix"?

    TimP: it's not clear the values that were picked were "right"
    in the context we are
    … but I don't think we have a good API or good ultimate
    settings
    … having a low-latency / fail-faster config would be good
    … instead of noodling with precise numbers of RTO

    Bernard: this sounds like an interesting idea, but probably as
    a different issue; this could be useful for media too

    Jan-Ivar: what would this low-latency look like? couldn't JS
    timeout faster based on whatever timing they want?

    Bernard: with unordered / unreliable, yes
    … with maxlifetime and maxretransmit

    Florent: it feels like there may be several features behind
    this request

    Bernard: sounds like consensus for "won't fix", with
    possibility of raising a different issue on low latency

     [27]Issue 107: maxFramerate probably should not be allowed in
     addTransceiver/setParameters for audio senders

      [27] https://github.com/w3c/webrtc-extensions/issues/107

    [28][Slide 12]

      [28] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=12

    Bernard: any objection to move forward with a pull request?

    [none expressed]

     [29]Issue 110: getDataChannels() method on RTCPeerConnection

      [29] https://github.com/w3c/webrtc-extensions/issues/110

    [30][Slide 13]

      [30] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=13

    Florent: if no objection, I'll submit a PR

    Jan-Ivar: +1 - will also help with garbage collection
    … it fits nicely with the model that the PC keeps data channels
    open and references to them

    RESOLUTION: getDataChannels() method on RTCPeerConnection ready
    for PR

    Florent: I think closed data channels shouldn't be part of the
    return values; probably matching the garbage collection algo of
    the spec

   WebRTC

     [31]Issue 2735: webrtc-pc specifies using ‘~’ in a=simulcast, but
     does not support RFC 7728 (RTP pause)

      [31] https://github.com/w3c/webrtc-pc/issues/2735

    [32][Slide 17]

      [32] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=17

    Jan-Ivar: +1

    Florent: we should probably add some language that ~ SHOULD NOT
    be supported for the said reasons

    Philipp the proposal is to not include in browser-generated
    O/A, and ignore it when received

    Dom: needs to check what JSEP says too

    Philipp: I'll work on Pull Request

     [33]#2746: Enum RTCIceCredentialType with only one value

      [33] https://github.com/w3c/webrtc-pc/issues/2746

    [34][Slide 18]

      [34] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=18

    Florent: given no implementation plan of using
    RTCIceCredentialType extension, see no reason to keep it

    Jan-Ivar: +1 on removing it until once we change our plans

    Dom: we could move the enum to webrtc-extensions

    Florent: I can work on a PR for both webrtc-pc &
    webrtc-extensions

     Issue [35]#2743: SLD/SRD (answer) trips over itself when narrowing
     simulcast envelope

      [35] https://github.com/w3c/webrtc-pc/issues/2743

    [36][Slide 19]

      [36] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=19

    Jan-Ivar: hopefully this is a non-controversial fix: fix the
    prose that it continues to allow answers to reject simulcast /
    layers on the initial offer

    [37][Slide 20]

      [37] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=20

    [no objection voiced]

    Bernard: so we'll label this issue as ready for PR

     [38]#2751 Intended outcome when modifying direction in
     have-local-offer

      [38] https://github.com/w3c/webrtc-pc/issues/2751

    [39][Slide 21]

      [39] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=21

    Jan-Ivar: any objection to reverting the change brought in
    [40]#2033?

      [40] https://github.com/w3c/webrtc-pc/issues/2033

    [none Voiced]

   WebRTC Simulcast issues

    Bernard: [41]#2722, [42]#2723 and [43]#2724 concern potential
    contradictions with RFC 8853

      [41] https://github.com/w3c/webrtc-pc/issues/2722
      [42] https://github.com/w3c/webrtc-pc/issues/2723
      [43] https://github.com/w3c/webrtc-pc/issues/2724

    [44][Slide 22]

      [44] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=22

     Issue [45]#2722: sRD(offer) completely overwrites pre-existing
     transceiver.[[Sender]].[[SendEncodings]]

      [45] https://github.com/w3c/webrtc-pc/issues/2722

    [46][Slide 23]

      [46] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=23

    Bernard: the problem was added in [47]PR #2155 - do we agree
    this was wrong?

      [47] https://github.com/w3c/webrtc-pc/pull/2155

    Jan-Ivar: the intent of that PR was to allow simulcast offers
    to populate the layers from an initial offer
    … the question is what to allow on subsequent offers
    … I'm hoping my slide on [48]#2724 might help job people's
    memories around this

      [48] https://github.com/w3c/webrtc-pc/issues/2724

     Issue [49]#2724: The language around setting a description appears
     to prohibit renegotiation of RIDs

      [49] https://github.com/w3c/webrtc-pc/issues/2724

    [50][Slide 28]

      [50] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=28

    jan-ivar: trying to assess what our intent was here, in
    particular with regard to how SFU behave
    … the first question is whether subsequent identical
    offer/answer should succeed because the net result is the same

    [no disagreement]
    … part of the more advanced questions is whether failing would
    violate RFC8853
    … how rigid should we after initial negotiation
    … should narrowing the simulcast envelop be allowed?
    … after having been narrowed, should it be allowed to expand
    back into the initial offer?

    florent: the latter could work, but not sure there is much
    point to it

    jan-ivar: there are 2 forms of rejection we might be talking
    about: reducing layers, and failing sRD

    florent: rejecting should be fine when asking for an expansion

    jan-ivar: so we could set an upper layer number based on the
    number of layers requested in the initial layer
    … what about limiting based on the number of layers accepted in
    the initial answer?

    bernard: the initial idea was to signal the maximum number of
    layers the peers can support with a minimal SDP surface

    jan-ivar: is the simulcast envelop is defined in the initial
    offer, or the combination of offer and answer?

    Bernard: I believe the latter

    florent: +1

    jan-ivar: but unclear how it interacts with sLD

    bernard: we need to avoid complicated error conditions

    jan-ivar: not clear that many apps handles well error in sLD /
    sRD
    … I'm hearing consensus on codifying the 1st one
    … while allowing future answers that match the initial offer
    provided they match the initial one
    … no appetite to fail on reducing the envelop; possibly even
    allowing it to expand back into the initial envelop

    Bernard: re RFC8853, it doesn't deal with the simulcast envelop
    - it allows things we don't to allow

    jan-ivar: it's mostly looking at initial offers

    [carine departs]

    Bernard: there are 2 concepts: the envelop in setParameters
    (the only one we mention in webrtc); then this notion in O/A of
    what is allowed

    Dom: is this more of an IETF matter?

    jan-ivar: this is specific to the PeerConnection client

    Bernard: JSEP doesn't say a thing about it

    Jan-ivar: we know that our current limitation is too strict -
    so we should loosen it a bit to match reality

    Bernard: and it's aligning it more with RFC8853 in any case

    Jan-Ivar: I'll work on a PR and check with Byron

    Florent: if we allow to renegotiate rids at the SDP level, we
    don't have a JS API to match
    … setParameters doesn't allow renegotiation
    … is that something we'll want in the future? allowing changing
    layers?

    Bernard: what would be the use case?

    Florent: if we allow it to happen at the SDP level, people will
    want to do it, and I would prefer we don't encourage SDP
    munging

    Bernard: still not sure that justifies its usefulness

     [51]#2722

      [51] https://github.com/w3c/webrtc-pc/issues/2722

    [52][Slide 23]

      [52] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=23

    jan-ivar: we need to add an exception on not stomping on
    addTransceiver

    Bernard: Byron had 2 suggestions: should we allow sRD(offer) to
    remove RIDs?

    Jan-Ivar: sounds like "no" based on our previous discussion
    … an already associated transceiver should not stomp on
    existing sendencodings

    [no disagreement voiced]

    Bernard: so let's mark [53]#2722 as ready for PR

      [53] https://github.com/w3c/webrtc-pc/issues/2722

     Issue [54]#2723: The prose around "simulcast envelope" falsely
     implies that simulcast encodings can never be removed

      [54] https://github.com/w3c/webrtc-pc/issues/2723

    [55][Slide 26]

      [55] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=26

    [56][Slide 25]

      [56] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=25

    Jan-Ivar: the original "simulcast envelope" was defined through
    addTransceivers; but does it make sense when the SFU enforces
    the offer?

    Bernard: we probably need a different term than "simulcast
    envelope" - this sounds like the right term for negotiation
    … but maybe not for interactions of addTransceivers /
    setParameters

    jan-ivar: we probably need to iterate based on the first
    loosening we have identified

    [57][Slide 27]

      [57] 
https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf#page=27

    Bernard: clearly our langauge on simulcast envelop is confusing

    Jan-Ivar: I'll work on a PR

   TPAC

    Bernard: next meeting at TPAC - reminder to register
    [58]https://www.w3.org/register/tpac2022

      [58] https://www.w3.org/register/tpac2022

Summary of resolutions

     1. [59]getDataChannels() method on RTCPeerConnection ready for
        PR

Received on Wednesday, 20 July 2022 08:18:21 UTC