14:47:06 <RRSAgent> RRSAgent has joined #rtp-transport
14:47:10 <RRSAgent> logging to https://www.w3.org/2024/09/25-rtp-transport-irc
14:47:10 <tpac-breakout-bot> RRSAgent, do not leave
14:47:11 <tpac-breakout-bot> RRSAgent, make logs public
14:47:12 <tpac-breakout-bot> Meeting: RtpTransport
14:47:12 <tpac-breakout-bot> Chair: Bernard Aboba, Peter Thatcher, Erik Språng
14:47:12 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/13
14:47:12 <Zakim> Zakim has joined #rtp-transport
14:47:13 <tpac-breakout-bot> Zakim, clear agenda
14:47:13 <Zakim> agenda cleared
14:47:13 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
14:47:14 <Zakim> agendum 1 added
14:47:14 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
14:47:14 <Zakim> agendum 2 added
14:47:14 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
14:47:15 <Zakim> agendum 3 added
14:47:15 <tpac-breakout-bot> Zakim, agenda+ Discussion
14:47:15 <Zakim> agendum 4 added
14:47:15 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
14:47:16 <Zakim> agendum 5 added
14:47:16 <tpac-breakout-bot> tpac-breakout-bot has left #rtp-transport
16:57:50 <hta> hta has joined #rtp-transport
16:58:09 <backkem> backkem has joined #rtp-transport
16:58:11 <markafoltz> markafoltz has joined #rtp-transport
16:59:08 <Orphis> Orphis has joined #rtp-transport
17:00:32 <solis> solis has joined #rtp-transport
17:02:50 <PeterThatcher> PeterThatcher has joined #rtp-transport
17:02:58 <PeterThatcher> I'm the note taker :)
17:03:09 <jesup> jesup has joined #rtp-transport
17:03:13 <henbos> henbos has joined #rtp-transport
17:03:18 <Bernd> Bernd has joined #rtp-transport
17:03:20 <hta> [slide 1] is apparently the magic for "we're currently on this slide"
17:03:35 <jh> jh has joined #rtp-transport
17:03:47 <markafoltz> Present+ Mark_Foltz
17:03:48 <chrisguttandin> chrisguttandin has joined #rtp-transport
17:04:34 <PeterThatcher> [slide 2]
17:04:42 <steely-glint7> steely-glint7 has joined #rtp-transport
17:04:58 <PeterThatcher> [slide 3]
17:05:09 <PeterThatcher> [slide 4]
17:05:11 <bdekoz0> bdekoz0 has joined #rtp-transport
17:05:27 <youenn> youenn has joined #rtp-transport
17:05:38 <PeterThatcher> [slide 5]
17:05:46 <vsviatetskyi> vsviatetskyi has joined #rtp-transport
17:06:08 <fluffy> fluffy has joined #rtp-transport
17:06:17 <joachimr> joachimr has joined #rtp-transport
17:06:25 <vsviatetskyi> hi
17:06:29 <PeterThatcher> [slide 6]
17:07:31 <PeterThatcher> [slide 7]
17:09:18 <PeterThatcher> [slide 8]
17:10:57 <PeterThatcher> [slide 9]
17:12:03 <Niko> Niko has joined #rtp-transport
17:14:21 <fluffy> q+
17:14:31 <PeterThatcher> [slide 10]
17:14:59 <okin> okin has joined #rtp-transport
17:15:17 <PeterThatcher> [slide 11]
17:15:56 <steely-glint> steely-glint has joined #rtp-transport
17:17:08 <youenn> youenn has joined #rtp-transport
17:17:51 <PeterThatcher> [slide 12]
17:18:43 <PeterThatcher> [slide 13]
17:21:19 <PeterThatcher> [slide 14]
17:23:21 <hta> q?
17:23:23 <PeterThatcher> [slide 16]
17:23:55 <Mo> Mo has joined #rtp-transport
17:24:13 <ekinnear> ekinnear has joined #rtp-transport
17:24:14 <Mo> q+
17:24:39 <ekinnear> q+
17:25:06 <mathis> mathis has joined #rtp-transport
17:25:28 <youenn> youenn has joined #rtp-transport
17:25:34 <jib> jib has joined #rtp-transport
17:26:25 <fluffy> q?
17:26:42 <markafoltz> q+
17:26:58 <JonathanLennox> JonathanLennox has joined #rtp-transport
17:27:20 <PeterThatcher> [slide 18]
17:27:31 <eugene> eugene has joined #rtp-transport
17:27:34 <PeterThatcher> Fluffy: How do you deal with consent?
17:27:51 <PeterThatcher> Harald: Still using ICE for consent, just like WebRTC is now.  No proposal to change that.
17:28:16 <PeterThatcher> Fluffy: Allow javascript-defined custom control?
17:28:29 <PeterThatcher> Fluffy: Do you have concerns?
17:28:34 <PeterThatcher> Harald: Yes, I have concerns
17:28:58 <PeterThatcher> Harald: We will insist on RTCP feedback messages being enabled, and then the browser interprets a BWE as well
17:29:04 <hyojin_> hyojin_ has joined #rtp-transport
17:29:07 <PeterThatcher> Harald: It's an open item
17:29:26 <PeterThatcher> Cullen: Circuit Breakers wasn't designed for this
17:29:42 <hta> ack fluffy
17:29:55 <jib> q+
17:30:37 <hta> s/we will insist/we may insist/ - it's still an item under discussion.
17:31:00 <JonathanLennox> RFC feedback is RFC 8888
17:31:03 <PeterThatcher> Mo: About [slide 13]: Which RTCP messages for CC?
17:32:05 <hta> ack mo
17:32:10 <PeterThatcher> Mo: What kind of RTCP messages are allowed?
17:32:13 <jesup> q+
17:32:28 <PeterThatcher> Peter: RTCP messages for CC is transport-cc or the RFC version
17:32:46 <PeterThatcher> Peter: RTCP is still in discussion, from fully custom to just "APP" to "use RTP instead of RTCP"
17:33:49 <PeterThatcher> 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?
17:34:24 <PeterThatcher> ekinnear:  Been discussing this in the IETF, and in relation to WebTransport
17:34:41 <PeterThatcher> ekinnear: Can we make the necessary signals available to everyone?
17:34:49 <markafoltz> markafoltz has joined #rtp-transport
17:35:50 <PeterThatcher> ekinnear:  We're moving everyone to avoid building queues
17:36:00 <hta> ack ekinnear
17:36:14 <PeterThatcher> ekinnear: In the CCWG in IETF, we're trying to modernize how we specify these things
17:39:09 <ekinnear> q+
17:39:46 <hta> ack markafoltz
17:39:50 <PeterThatcher> Peter:  long-winded response I coulcn't write while talking :)
17:41:02 <PeterThatcher> 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.
17:41:16 <PeterThatcher> markafoltz: Can we send any RTCP?
17:41:41 <PeterThatcher> Harald: ??? (Sorry, I'm slow typing; please check the recording :)
17:42:00 <steely-glint> steely-glint has joined #rtp-transport
17:42:25 <hta> .... there is no recording ...
17:42:26 <PeterThatcher> Jan-Ivar:  Workers?
17:42:36 <PeterThatcher> Peter: This is an "old" example.  It will have Workers.
17:42:55 <hta> when using standard formats, they need to conform with standards. there are places to do completely custom things within the RTP specs.
17:43:01 <youenn> +q
17:43:04 <hta> ack jib
17:43:25 <PeterThatcher> 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?
17:43:40 <PeterThatcher> Harald: Custom bitrate allocation is more interesting
17:44:01 <hta> ack jesup
17:44:13 <PeterThatcher> jesup: Custom congestion control is risky to the web
17:44:15 <hta> zakim, close the queue
17:44:15 <Zakim> ok, hta, the speaker queue is closed
17:44:36 <PeterThatcher> ekinnear: Going lower than what a browser is good, but you can do that today
17:44:54 <jesup> Jesup, harald: changing the division of bandwidth is more interesting than new congestion controls
17:44:58 <nidhijaju7> nidhijaju7 has joined #rtp-transport
17:45:48 <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.
17:46:50 <hta> ack ekinnear
17:47:08 <PeterThatcher> Peter: We're providing information to the JS to allow it to do a better job of "going lower"
17:47:20 <PeterThatcher> youenn: This is about "opening the box"
17:48:03 <PeterThatcher> 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.
17:48:11 <hta> ack youenn
17:48:18 <PeterThatcher> youenn: We can ship some things before we solve all the problems
17:50:11 <PeterThatcher> 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
17:50:29 <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.
17:50:54 <PeterThatcher> I think youenn meant we can ship lots of parts of RtpTransport without/before shipping the CC part.
17:51:07 <fluffy> q+
17:51:21 <handellm> handellm has joined #rtp-transport
17:51:26 <PeterThatcher> The built-in CC is the same as the existing one, if the custom CC isn't enabled.
17:51:52 <PeterThatcher> [slide 21]
17:51:53 <baboba> baboba has joined #rtp-transport
17:52:00 <baboba> +q
17:52:44 <Mo> +q
17:52:45 <fluffy> q+
17:52:46 <hta> zakim, open the queue
17:52:46 <Zakim> ok, hta, the speaker queue is open
17:52:54 <fluffy> q+
17:52:55 <jesup> q+
17:53:16 <hta> ack fluffy
17:53:37 <Mo> q+
17:53:55 <PeterThatcher> fluffy: I'd want to use it for interop with devices that are very basic (still ICE): voice only, particularly PSTN gateways
17:54:12 <PeterThatcher> Harald: SRTP?
17:54:24 <PeterThatcher> fluffy: Ideally, no ICE and SRTP, but we can't drop those
17:54:36 <PeterThatcher> fluffy: can we minimize the stuff I need to implement?
17:54:53 <PeterThatcher> Bernard: G711?  RTCP?
17:55:03 <PeterThatcher> fluffy: RTCP is fine.  I prefer SDES over DTLS
17:55:15 <jesup> q-
17:55:17 <PeterThatcher> fluffy: ICE lite is enough
17:55:39 <markafoltz> q+
17:55:43 <joachimr> q+
17:55:44 <fluffy> ack fluffy
17:55:51 <flackr> flackr has joined #rtp-transport
17:55:52 <PeterThatcher> Mo: Most important is alternate codecs
17:56:00 <jesup> q+
17:56:05 <PeterThatcher> Mo: Can't constrain yourself to SDP, in that case
17:56:19 <PeterThatcher> Harald: We have another thread for customizing codecs in SDP
17:56:39 <PeterThatcher> Mo: Can we overwrite standard codecs?
17:56:40 <hta> ack mo
17:56:46 <PeterThatcher> Peter: Yes, definitely overwrite standard codecs
17:57:16 <PeterThatcher> markfoltz: Google cast protocol is based on RTP... would it be compatible?
17:57:54 <hta> ack markafoltz
17:58:12 <hta> ack joachimr
17:58:13 <PeterThatcher> Peter: I think you could do the cast-version of RTP
17:58:39 <PeterThatcher> joachimr: This would be useful for porting mobile code to the web app
17:59:08 <PeterThatcher> joachimr: For need custom bitrate allocation for FEC, etc (?)
17:59:24 <PeterThatcher> joachimr: Having the option of custom congestion control seems really useful (?)
17:59:26 <hta> q?
18:00:03 <PeterThatcher> Jesup: You shouldn't need to conform to SDP.  If you control both ends, do what you want.
18:00:29 <PeterThatcher> Elad: SDP is needed for initialization, at least at the moment
18:00:49 <PeterThatcher> Jesup: I meant more that you don't need to conform to the codecs negotiated
18:00:53 <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.
18:00:56 <jib> s/Elad/Orphis/
18:00:58 <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
18:01:09 <PeterThatcher> Harald: if you control both ends, it's probably fine
18:02:01 <PeterThatcher> 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.
18:02:31 <baboba> Someone should pursue...
18:02:40 <PeterThatcher> Raise hand for "should pursue"
18:03:01 <henbos> Someone should pursuit this
18:03:07 <Mo> Should pursue +1
18:03:07 <fluffy> +1 pursue
18:03:07 <vsviatetskyi> Should pursue +1
18:03:07 <steely-glint> Should pursue +1
18:03:07 <PeterThatcher> I'll join a group :)
18:03:07 <baboba> One point: many of the use cases involve audio.  I am not clear that we have adequate info.
18:03:10 <fluffy> No on join group
18:03:15 <baboba> Would join a CG.
18:03:15 <steely-glint> I'll join a group.
18:03:26 <jesup> no on join.   skeptical of persuing
18:03:28 <fluffy> I would join a WG
18:03:45 <Mo> I'll join a group +1
18:03:49 <eugene> eugene has joined #rtp-transport
18:04:20 <PeterThatcher> fluffy: WGs are more effective than CGs
18:04:59 <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)
18:05:07 <vsviatetskyi> thanks
18:05:53 <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
18:07:15 <PeterThatcher> About FEC: Yes, that's true.  It's orthogonal to RtpTransport, but yeah, having more FEC control for WebRTC would be good.
18:13:49 <jesup> jesup has left #rtp-transport
18:17:18 <markafoltz> markafoltz has joined #rtp-transport
18:37:30 <chrisguttandin> chrisguttandin has left #rtp-transport
19:28:29 <markafoltz> markafoltz has joined #rtp-transport
20:02:33 <backkem> backkem has left #rtp-transport
20:10:01 <markafoltz> markafoltz has joined #rtp-transport
20:20:13 <flackr> flackr has left #rtp-transport
21:50:04 <markafoltz> markafoltz has joined #rtp-transport
23:26:38 <markafoltz> markafoltz has joined #rtp-transport
23:58:26 <markafoltz> markafoltz has joined #rtp-transport