Meeting minutes
I'm the note taker :)
<hta> [slide 1] is apparently the magic for "we're currently on this slide"
Slideset: https://
<vsviatetskyi> hi
Fluffy: How do you deal with consent?
Harald: Still using ICE for consent, just like WebRTC is now. No proposal to change that.
Fluffy: Allow javascript-defined custom control?
Fluffy: Do you have concerns?
Harald: Yes, I have concerns
Harald: We will insist on RTCP feedback messages being enabled, and then the browser interprets a BWE as well
Harald: It's an open item
Cullen: Circuit Breakers wasn't designed for this
<hta> s/we will insist/we may insist/ - it's still an item under discussion.
<JonathanLennox> RFC feedback is RFC 8888
Mo: About [slide 13]: Which RTCP messages for CC?
Mo: What kind of RTCP messages are allowed?
Peter: RTCP messages for CC is transport-cc or the RFC version
Peter: RTCP is still in discussion, from fully custom to just "APP" to "use RTP instead of RTCP"
ekinnear: If we think there is a "right enough" answer for congestion control, give feedback about what is being seen by the safety check? Why not just give that value? And why not allow the web app to say what it wants from the CC?
ekinnear: Been discussing this in the IETF, and in relation to WebTransport
ekinnear: Can we make the necessary signals available to everyone?
ekinnear: We're moving everyone to avoid building queues
ekinnear: In the CCWG in IETF, we're trying to modernize how we specify these things
Peter: long-winded response I coulcn't write while talking :)
Peter: something like 1. We're making all the signals available, 2. It's designed to let new ideas, like from the IETF, be prototype/experimented, 3. It's safe to go below the browser's BWE, 4. Going above the browser's BWE might be acceptable for brief bursts of probing.
markafoltz: Can we send any RTCP?
Harald: ??? (Sorry, I'm slow typing; please check the recording :)
<hta> .... there is no recording ...
Jan-Ivar: Workers?
Peter: This is an "old" example. It will have Workers.
<hta> when using standard formats, they need to conform with standards. there are places to do completely custom things within the RTP specs.
jesup: Congestion Control is hard. The browser should have guard rails, and if you have guard rails, then what do you gain from custom CC?
Harald: Custom bitrate allocation is more interesting
jesup: Custom congestion control is risky to the web
ekinnear: Going lower than what a browser is good, but you can do that today
<jesup> Jesup, harald: changing the division of bandwidth is more interesting than new congestion controls
<fluffy> I will point out that when you have two congestion controller running at the same time on the same data, it seems very hard to model and debug. You end up with two control loops that interact with each other.
Peter: We're providing information to the JS to allow it to do a better job of "going lower"
youenn: This is about "opening the box"
youenn: Maybe our V1 is about "opening the box" for easier things like packetization, and header extensions that are standardized but not implemented, and maybe the harder issue and congestion control is V2.
youenn: We can ship some things before we solve all the problems
Erik: This implements the same googcc algorithm as in libwebrtc, but without probing because we can't yet set the send time of the RTP packet
<fluffy> I'm all for shipping before all problems solved. However, I'm against shipping stuff that is not safe and can be used for widespread DDoS so it seems critical to have a safe congesiton control solution before shipping.
I think youenn meant we can ship lots of parts of RtpTransport without/before shipping the CC part.
The built-in CC is the same as the existing one, if the custom CC isn't enabled.
fluffy: I'd want to use it for interop with devices that are very basic (still ICE): voice only, particularly PSTN gateways
Harald: SRTP?
fluffy: Ideally, no ICE and SRTP, but we can't drop those
fluffy: can we minimize the stuff I need to implement?
Bernard: G711? RTCP?
fluffy: RTCP is fine. I prefer SDES over DTLS
fluffy: ICE lite is enough
Mo: Most important is alternate codecs
Mo: Can't constrain yourself to SDP, in that case
Harald: We have another thread for customizing codecs in SDP
Mo: Can we overwrite standard codecs?
Peter: Yes, definitely overwrite standard codecs
markfoltz: Google cast protocol is based on RTP... would it be compatible?
Peter: I think you could do the cast-version of RTP
joachimr: This would be useful for porting mobile code to the web app
joachimr: For need custom bitrate allocation for FEC, etc (?)
joachimr: Having the option of custom congestion control seems really useful (?)
Jesup: You shouldn't need to conform to SDP. If you control both ends, do what you want.
Orphis: SDP is needed for initialization, at least at the moment
Jesup: I meant more that you don't need to conform to the codecs negotiated
<markafoltz> Cast also has a proprietary format for RTCP ACKs/NACKs (empty RR + custom bitfields) so I was asking if the API would be able to parse ACKS/NACKs from that.
<joachimr> For bitrate allocation example: need ability to choose amount of bitrate you allocate to video/audio encoding and FEC or RTX, don't see support for this in the current API outline
Harald: if you control both ends, it's probably fine
About bitrate allocation with FEC/RTX: you could definitely do that the API if you do custom FEC and custom RTX and not rely on the built-in FEC and RTX.
<baboba> Someone should pursue...
Raise hand for "should pursue"
<henbos> Someone should pursuit this
<Mo> Should pursue +1
<fluffy> +1 pursue
<vsviatetskyi> Should pursue +1
<steely-glint> Should pursue +1
I'll join a group :)
<baboba> One point: many of the use cases involve audio. I am not clear that we have adequate info.
<fluffy> No on join group
<baboba> Would join a CG.
<steely-glint> I'll join a group.
<jesup> no on join. skeptical of persuing
<fluffy> I would join a WG
<Mo> I'll join a group +1
fluffy: WGs are more effective than CGs
<joachimr> Re FEC: Yes, possible if you do custom FEC, but would also be nice to be able to only do custom bandwidth allocation to select amount of FEC applied via the browser's built-in FEC algo (whether ulpfec or flexfec)
<vsviatetskyi> thanks
<Orphis> fluffy: We do have participation from 3 vendors at the moment on the specification, so risks of this being a specific vendor's pet project are low
About FEC: Yes, that's true. It's orthogonal to RtpTransport, but yeah, having more FEC control for WebRTC would be good.