14:31:48 <RRSAgent> RRSAgent has joined #webrtc
14:31:48 <RRSAgent> logging to https://www.w3.org/2022/07/19-webrtc-irc
14:59:50 <fippo> fippo has joined #webrtc
15:05:47 <dom> Present: Bernard, Jan-Ivar, Philipp, Florent, Carine, Dom, TimP
15:06:26 <dom> Recording is starting
15:06:26 <dom> Recording: https://www.youtube.com/watch?v=k0IN7_zMBo8
15:06:26 <dom> Meeting: WebRTC July 2022 meeting
15:06:32 <dom> Chair: Bernard, Jan-Ivar
15:06:43 <dom> Regrets: Harald, Elad
15:07:18 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/Main_Page
15:07:57 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Jul/att-0002/WEBRTCWG-2022-07-19.pdf
15:08:50 <dom> Topic: WebRTC Extensions
15:09:06 <dom> Subtopic: -> https://github.com/w3c/webrtc-extensions/issues/71 Add SCTP rate control params to RTCPeerConnection constructor
15:09:14 <dom> [slide 11]
15:09:45 <dom> Bernard: filed by someone writing a terminal app - would apply to a PC or the cloud
15:09:51 <dom> s/PC or/PC in/
15:10:10 <dom> ... problems with exponential RTO backoffs
15:10:57 <dom> ... can we give developer control to these values which are tricky to get right?
15:11:36 <dom> ... typically apps would use unreliable unordered transport and deal with this themselves
15:12:16 <dom> ... not clear we need to allow this. any objection to "won't fix"?
15:12:35 <dom> TimP: it's not clear the values that were picked were "right" in the context we are
15:12:57 <dom> ... but I don't think we have a good API or good ultimate settings
15:13:43 <dom> ... having a low-latency / fail-faster config would be good
15:13:58 <dom> ... instead of noodling with precise numbers of RTO
15:14:23 <dom> Bernard: this sounds like an interesting idea, but probably as a different issue; this could be useful for media too
15:15:00 <dom> Jan-Ivar: what would this low-latency look like? couldn't JS timeout faster based on whatever timing they want?
15:15:10 <dom> Bernard: with unordered / unreliable, yes
15:16:02 <dom> ... with maxlifetime and maxretransmit
15:17:23 <dom> Florent: it feels like there may be several features behind this request
15:18:16 <dom> Bernard: sounds like consensus for "won't fix", with possibility of raising a different issue on low latency
15:18:41 <dom> Subtopic: -> https://github.com/w3c/webrtc-extensions/issues/107 Issue 107: maxFramerate probably should not be allowed in addTransceiver/setParameters for audio senders
15:18:44 <dom> [slide 12]
15:18:58 <dom> Bernard: any objection to move forward with a pull request?
15:19:01 <dom> [none expressed]
15:19:20 <dom> Subtopic: -> https://github.com/w3c/webrtc-extensions/issues/110 Issue 110: getDataChannels() method on RTCPeerConnection
15:19:23 <dom> [slide 13]
15:21:24 <dom> Florent: if no objection, I'll submit a PR
15:21:37 <dom> Jan-Ivar: +1 - will also help with garbage collection
15:22:12 <dom> ... it fits nicely with the model that the PC keeps data channels open and references to them
15:22:29 <dom> RESOLVED: getDataChannels() method on RTCPeerConnection ready for PR
15:23:46 <dom> Florent: I think closed data channels shouldn't be part of the return values; probably matching the garbage collection algo of the spec
15:23:58 <dom> Topic: WebRTC
15:24:16 <dom> Subtopic: -> https://github.com/w3c/webrtc-pc/issues/2735 Issue 2735: webrtc-pc specifies using ‘~’ in a=simulcast, but does not support RFC 7728 (RTP pause)
15:24:31 <dom> Repository: https://github.com/w3c/webrtc-pc/
15:24:35 <dom> [slide 17]
15:25:41 <dom> Jan-Ivar: +1
15:26:26 <dom> Florent: we should probably add some language that ~ SHOULD NOT be supported for the said reasons
15:27:15 <dom> Philip: the proposal is to not include in browser-generated O/A, and ignore it when received
15:28:58 <dom> Dom: needs to check what JSEP says too
15:31:23 <dom> Philipp: I'll work on Pull Request
15:31:29 <dom> s/Philip:/Philipp/
15:32:02 <dom> Subtopic: #2746: Enum RTCIceCredentialType with only one value
15:32:27 <dom> Florent: given no implementation plan of using RTCIceCredentialType extension, see no reason to keep it
15:32:56 <dom> Jan-Ivar: +1 on removing it until once we change our plans
15:34:34 <dom> Dom: we could move the enum to webrtc-extensions
15:35:22 <dom> Florent: I can work on a PR for both webrtc-pc & webrtc-extensions
15:35:59 <dom> Subtopic: Issue #2743: SLD/SRD (answer) trips over itself when narrowing simulcast envelope
15:36:10 <dom> [slide 19]
15:36:17 <dom> i/Florent: given/[slide 18]
15:38:26 <dom> 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
15:38:48 <dom> [slide 20]
15:39:05 <dom> [no objection voiced]
15:39:31 <dom> Bernard: so we'll label this issue as ready for PR
15:40:16 <dom> Subtopic: #2751 Intended outcome when modifying direction in have-local-offer
15:40:21 <dom> [slide 21]
15:43:33 <dom> Jan-Ivar: any objection to reverting the change brought in #2033?
15:43:37 <dom> [none voice]
15:43:50 <dom> s/voice/Voiced
15:44:00 <dom> Topic: WebRTC Simulcast issues
15:44:32 <dom> Bernard: #2722, #2723 and #2724 concern potential contradictions with RFC 8853
15:44:47 <dom> [slide 22]
15:45:01 <dom> Subtopic: Issue #2722: sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]]
15:45:06 <dom> [slide 23]
15:47:19 <dom> Bernard: the problem was added in PR #2155 - do we agree this was wrong?
15:47:35 <dom> Jan-Ivar: the intent of that PR was to allow simulcast offers to populate the layers from an initial offer
15:47:43 <dom> ... the question is what to allow on subsequent offers
15:48:03 <dom> ... I'm hoping my slide on #2724 might help job people's memories around this
15:48:28 <dom> Subtopic: Issue #2724: The language around setting a description appears to prohibit renegotiation of RIDs
15:48:34 <dom> [slide 28]
15:49:29 <dom> RRSAgent, draft minutes
15:49:29 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/19-webrtc-minutes.html dom
15:51:44 <dom> jan-ivar: trying to assess what our intent was here, in particular with regard to how SFU behave
15:52:20 <dom> ... the first question is whether subsequent identical offer/answer should succeed because the net result is the same
15:52:27 <dom> [no disagreement]
15:53:22 <dom> ... part of the more advanced questions is whether failing would violate RFC8853
15:53:59 <dom> ... how rigid should we after initial negotiation
15:54:25 <dom> ... should narrowing the simulcast envelop be allowed?
15:56:16 <dom> ... after having been narrowed, should it be allowed to expand back into the initial offer?
15:57:10 <dom> florent: the latter could work, but not sure there is much point to it
15:57:28 <dom> jan-ivar: there are 2 forms of rejection we might be talking about: reducing layers, and failing sRD
15:58:35 <dom> florent: rejecting should be fine when asking for an expansion
15:59:18 <dom> jan-ivar: so we could set an upper layer number based on the number of layers requested in the initial layer
15:59:33 <dom> ... what about limiting based on the number of layers accepted in the initial answer?
16:00:12 <dom> bernard: the initial idea was to signal the maximum number of layers the peers can support with a minimal SDP surface
16:01:02 <dom> jan-ivar: is the simulcast envelop is defined in the initial offer, or the combination of offer and answer?
16:01:08 <dom> Bernard: I believe the latter
16:01:10 <dom> florent: +1
16:01:51 <dom> jan-ivar: but unclear how it interacts with sLD
16:02:02 <dom> bernard: we need to avoid complicated error conditions
16:02:15 <dom> jan-ivar: not clear that many apps handles well error in sLD / sRD
16:02:30 <dom> ... I'm hearing consensus on codifying the 1st one
16:02:54 <dom> ... while allowing future answers that match the initial offer provided they match the initial one
16:03:15 <dom> ... no appetite to fail on reducing the envelop; possibly even allowing it to expand back into the initial envelop
16:04:07 <dom> Bernard: re RFC8853, it doesn't deal with the simulcast envelop - it allows things we don't to allow
16:04:27 <dom> jan-ivar: it's mostly looking at initial offers
16:05:20 <dom> [carine departs]
16:07:57 <dom> 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
16:08:11 <dom> Dom: is this more of an IETF matter?
16:08:19 <dom> jan-ivar: this is specific to the PeerConnection client
16:08:25 <dom> Bernard: JSEP doesn't say a thing about it
16:10:42 <dom> Jan-ivar: we know that our current limitation is too strict - so we should loosen it a bit to match reality
16:11:00 <dom> Bernard: and it's aligning it more with RFC8853 in any case
16:11:41 <dom> Jan-Ivar: I'll work on a PR and check with Byron
16:12:17 <dom> Florent: if we allow to renegotiate rids at the SDP level, we don't have a JS API to match
16:12:27 <dom> ... setParameters doesn't allow renegotiation
16:12:47 <dom> ... is that something we'll want in the future? allowing changing layers?
16:12:55 <dom> Bernard: what would be the use case?
16:13:19 <dom> 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
16:13:41 <dom> Bernard: still not sure that justifies its usefulness
16:13:57 <dom> Subtopic: #2722
16:15:23 <dom> [slide 23]
16:16:04 <dom> jan-ivar: we need to add an exception on not stomping on addTransceiver
16:16:23 <dom> Bernard: Byron had 2 suggestions: should we allow sRD(offer) to remove RIDs?
16:16:31 <dom> Jan-Ivar: sounds like "no" based on our previous discussion
16:17:38 <dom> ... an already associated transceiver should not stomp on existing sendencodings
16:17:49 <dom> [no disagreement voiced]
16:18:01 <dom> Bernard: so let's mark #2722 as ready for PR
16:18:21 <dom> Subtopic: Issue #2723: The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed
16:20:13 <dom> [slide 26]
16:20:24 <dom> [slide 25]
16:25:30 <dom> Jan-Ivar: the original "simulcast envelope" was defined through addTransceivers; but does it make sense when the SFU enforces the offer?
16:28:38 <dom> Bernard: we probably need a different term than "simulcast envelope" - this sounds like the right term for negotiation
16:28:51 <dom> ... but maybe not for interactions of addTransceivers / setParameters
16:30:37 <dom> jan-ivar: we probably need to iterate based on the first loosening we have identified
16:34:06 <dom> [slide 27]
16:34:21 <dom> Bernard: clearly our langauge on simulcast envelop is confusing
16:34:25 <dom> Jan-Ivar: I'll work on a PR
16:35:30 <dom> RRSAgent, draft minutes
16:35:30 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/19-webrtc-minutes.html dom
16:37:29 <dom> Topic: TPAC
16:37:39 <dom> Bernard: next meeting at TPAC - reminder to register https://www.w3.org/register/tpac2022
16:37:43 <dom> RRSAgent, draft minutes
16:37:43 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/19-webrtc-minutes.html dom
16:37:56 <dom> RRSAgent, make log public