W3C

– DRAFT –
WebRTC July 2022 meeting

19 July 2022

Attendees

Present
Bernard, Carine, Dom, Florent, Jan-Ivar, Philipp, TimP
Regrets
Elad, Harald
Chair
Bernard, Jan-Ivar
Scribe
dom

Meeting minutes

Recording: https://www.youtube.com/watch?v=k0IN7_zMBo8

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

WebRTC Extensions 🎞︎

Add SCTP rate control params to RTCPeerConnection constructor 🎞︎

[Slide 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

Issue 107: maxFramerate probably should not be allowed in addTransceiver/setParameters for audio senders 🎞︎

[Slide 12]

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

[none expressed]

Issue 110: getDataChannels() method on RTCPeerConnection 🎞︎

[Slide 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 🎞︎

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

[Slide 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

#2746: Enum RTCIceCredentialType with only one value 🎞︎

[Slide 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 #2743: SLD/SRD (answer) trips over itself when narrowing simulcast envelope 🎞︎

[Slide 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

[Slide 20]

[no objection voiced]

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

#2751 Intended outcome when modifying direction in have-local-offer 🎞︎

[Slide 21]

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

[none Voiced]

WebRTC Simulcast issues 🎞︎

Bernard: #2722, #2723 and #2724 concern potential contradictions with RFC 8853

[Slide 22]

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

[Slide 23]

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

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 #2724 might help job people's memories around this

Issue #2724: The language around setting a description appears to prohibit renegotiation of RIDs 🎞︎

[Slide 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

#2722 🎞︎

[Slide 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 #2722 as ready for PR

Issue #2723: The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed 🎞︎

[Slide 26]

[Slide 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

[Slide 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 https://www.w3.org/register/tpac2022

Summary of resolutions

  1. getDataChannels() method on RTCPeerConnection ready for PR
Minutes manually created (not a transcript), formatted by scribe.perl version repo-links-187 (Sat Jan 8 20:22:22 2022 UTC).