Meeting minutes
Recording: https://
Slideset: https://
WebRTC Extensions 🎞︎
Add SCTP rate control params to RTCPeerConnection constructor 🎞︎
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 🎞︎
Bernard: any objection to move forward with a pull request?
[none expressed]
Issue 110: getDataChannels() method on RTCPeerConnection 🎞︎
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) 🎞︎
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 🎞︎
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 🎞︎
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
[no objection voiced]
Bernard: so we'll label this issue as ready for PR
#2751 Intended outcome when modifying direction in have-local-offer 🎞︎
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
Issue #2722: sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]] 🎞︎
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 🎞︎
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 🎞︎
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 🎞︎
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
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://