15:47:21 <RRSAgent> RRSAgent has joined #webrtc
15:47:25 <RRSAgent> logging to https://www.w3.org/2024/09/24-webrtc-irc
15:47:25 <Zakim> Zakim has joined #webrtc
15:47:33 <dom> Meeting: WebRTC WG Meeting at TPAC 2024
15:48:30 <dom> Present+ Fippo, Joachim, Markus, Harald, Dom, Fredrik
15:48:41 <dom> Aged
15:48:44 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/September_24_2024
15:48:46 <dom> s/Aged//
15:48:56 <dom> Chair: Harald, Jan-Ivar, Bernard
15:49:21 <dom> Slideset: https://docs.google.com/presentation/d/1dFntwgSd9MrLnd1Sf58eBHstkodUd30WSKGIaK5K2CM/
15:55:36 <dom> Present+ Younn, MarkFoltz, MartinT
15:56:32 <dom> Present+ Cullen, Tove
15:57:15 <dom> Present+ Bernard
15:57:32 <dom> Present+ Florent
15:57:42 <dom> Present+ Guido
15:58:32 <dom> Present+ ErikC
15:59:06 <dom> Present+ HenrikB
15:59:49 <okin> okin has joined #webrtc
16:01:55 <dom> scribe+
16:02:08 <joachimr> joachimr has joined #webrtc
16:02:13 <youenn> youenn has joined #webrtc
16:02:30 <dom> Present+ Sameer, GabrielBrito
16:02:49 <rahsin-msft> rahsin-msft has joined #webrtc
16:02:57 <hta> hta has joined #webrtc
16:03:35 <solis> solis has joined #webrtc
16:03:57 <dom> Present+ Jan-Ivar
16:04:12 <SteveBecker> SteveBecker has joined #webrtc
16:04:30 <ericc> ericc has joined #webrtc
16:04:44 <dom> s/kC/cC
16:05:53 <fluffy> fluffy has joined #webrtc
16:05:53 <dom> Recording is starting
16:07:17 <dom> Present+ Sun
16:08:32 <markafoltz> markafoltz has joined #webrtc
16:08:38 <markafoltz> Present+ Mark_Foltz
16:08:44 <peter> peter has joined #webrtc
16:08:49 <henbos> henbos has joined #webrtc
16:08:50 <handellm> handellm has joined #webrtc
16:08:59 <henbos> Hello world
16:09:06 <jib> jib has joined #webrtc
16:09:23 <dom> Topic: State of the WG
16:09:23 <dom> [slide 10]
16:09:26 <dom> Present+ Elad
16:09:26 <fluffy> I'm actually lost on how we get in the speaker Q.
16:09:45 <peter> "raise hand"?
16:09:49 <steely-glint> steely-glint has joined #webrtc
16:10:08 <handellm> +queue?
16:10:12 <peter> You can use "raise hand" on zoom?  I thought the slide said IRC was required.
16:10:14 <dom> q+
16:10:16 <dom> q-
16:10:21 <dom> q-?
16:10:24 <fluffy> thx
16:10:30 <dom> Present+ TimP
16:10:39 <dom> Present+ Carine
16:10:57 <dom> Present+ JasperHugo
16:11:04 <jib> Present+ jib
16:11:39 <dom> [slide 11]
16:11:45 <dom> RRSAgent, draft minutes
16:11:46 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-webrtc-minutes.html dom
16:11:58 <dom> RRSAgent, make minutes public
16:11:58 <RRSAgent> I'm logging. I don't understand 'make minutes public', dom.  Try /msg RRSAgent help
16:12:09 <dom> RRSAgent, make log public
16:12:50 <dom> [slide 12]
16:13:32 <dom> [slide 13]
16:14:41 <dom> [slide 14]
16:15:49 <jib> q+
16:15:57 <dom> ack jib
16:15:59 <youenn> youenn has joined #webrtc
16:16:32 <dom> jib: Firefox 132 is now shipping (in nightly) with a more private enumerateDevices, an important step towards moving forward to Rec
16:16:46 <dom> ... progress on implementing in mediacapture-transform in FF and Safari
16:16:52 <dom> ... and some progress in webrtc-trancsform as well
16:16:53 <dom> q?
16:16:54 <hta> q?
16:17:03 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/3001 Updating the W3C Recommendation
16:17:03 <dom> [slide 17]
16:17:09 <jib> q-
16:22:03 <mjwilson> mjwilson has joined #webrtc
16:22:09 <youenn> youenn: heavyweight process. Why not simplify the process?
16:22:50 <youenn> dom: some amendments are not implemented twice, that is the main filter for amendments that can move forward and other amendments.
16:23:18 <baboba> baboba has joined #webrtc
16:23:35 <vr000m> vr000m has joined #webrtc
16:23:48 <youenn> youenn: how do we tracks not fully implemented amendments
16:23:56 <youenn> dom: there is a page with the list.
16:24:13 <kota> kota has joined #webrtc
16:24:16 <youenn> dom: going through the list of amendments that can move forward.
16:25:21 <fluffy> q+
16:27:22 <youenn> fluffy: are we tracking changes that could trigger backward incompatibility?
16:28:30 <youenn> dom: this is something that is being discussed for each amendment. New API is ok. Other changes might be related to clarifications/alignment of implementations are unlikely to have backward incompatibility.
16:28:45 <fluffy> q-
16:29:04 <youenn> bernard: for some issues, backward compatibility concerns have been raised (which number???)
16:30:28 <dom> [slide 18]
16:30:31 <dom> [slide 19]
16:30:34 <dom> [slide 20]
16:30:36 <dom> [slide 21]
16:31:01 <dom> Youenn: for any new amendment for behavior, we should file engine bugs and keep link in the github issues
16:31:31 <fluffy> which browsers should we file bugs on ?
16:31:33 <hta> q+
16:31:40 <dom> Dom: this could be even enforced automatically through the amendment process
16:31:51 <dom> Youenn: maybe let's first ask editors to keep that in mind
16:32:05 <dom> HTA: WPT can attach bugs to failing tests
16:32:16 <dom> ack hta
16:32:46 <fluffy> Huge THANK YOU to Dom
16:33:23 <dom> HTA: any objection to proceed with that plan?
16:33:38 <dom> RESOLVED: Proceed with publishing proposed amendments as described
16:33:53 <dom> Topic: Codec Issues
16:33:53 <dom> Subtopic: Making Codecs Transceiver-specific
16:33:53 <dom> [slide 24]
16:35:05 <dom> q+ Bernard
16:35:19 <dom> Present+ Randell
16:36:05 <dom> [slide 25]
16:36:45 <peter> Just don't use "sendrecv" :)
16:36:57 <steely-glint> FYI I _think_ RTCCertificate.expires change _is_ observable via base64Certificate stats - I'd be happy to work with someone to implement a test...
16:37:39 <dom> [slide 26]
16:38:34 <peter> q+
16:39:35 <dom> Bernard: the question of what a codec means has been raised; e.g. for H265 not all profiles are necessarily meant to be supported
16:40:10 <dom> Henrik: in terms of negotiating payload types, this is a side problem - that I'm ignoring for now
16:40:36 <hta> q?
16:40:49 <dom> ack Bernard
16:40:51 <dom> ack Peter
16:41:05 <dom> Peter: what about saying "don't use sendrecv"?
16:41:12 <dom> [slide 27]
16:42:20 <fluffy> q+
16:42:49 <dom> ack fluffy
16:43:16 <dom> fluffy: why would you mark something as sendrecv if you can't send & receive?
16:43:24 <dom> bernard: this may also lead to offering wrong profiles
16:43:57 <dom> fluffy: what is the motivation for this?
16:44:26 <dom> henrik: we have been living so far in a world where most codecs were sendrecv
16:44:40 <dom> fluffy: the codecs are almost never symetric
16:45:18 <fluffy> q-
16:45:19 <dom> [slide 28]
16:46:13 <dom> henrik: proposal A is the least powerful option, and may not be backwards compatible given what I hear about profiles
16:47:36 <dom> ... I would lean towards B among A, B, C
16:47:47 <dom> ... D is about relaxing the RFC expectations
16:48:41 <dom> Harald: the RFC language is ambiguous - "indicate codecs" can be interpreted in 2 ways
16:48:42 <peter> q+
16:48:57 <dom> ... the codec number is included in the m-line, or it is included in an rtpmap line
16:49:31 <dom> ... if you get a payload type suggestion for a codec, you can certainly include that codec in your answer and say you're willing to receive it by including it in your m-line
16:49:41 <dom> ... but SDP has been unclear about allowing to do this
16:49:53 <baboba> +q
16:49:54 <dom> Henrik: I like it for this reason, but there is no API to check the rtpmap line
16:50:09 <dom> ... but it still ends up excluding anything not in the preference lists
16:50:12 <dom> s/lists/list
16:50:12 <youenn> +q
16:50:29 <jib> q+
16:50:31 <fluffy> q+
16:50:45 <dom> Peter: my proposal E: if you want recvonky codecs, you create a recvonly transceiver
16:50:58 <dom> Henrik: that's proposal A - it avoids the footgun
16:51:01 <dom> ack peter
16:51:04 <dom> ack baboba
16:51:18 <joachimr> joachimr has joined #webrtc
16:51:20 <dom> Bernard: I also like A - it gives significant clarity
16:51:44 <hta> q+
16:51:45 <dom> ... e.g. going through profiles, you'd indicate the highest profile you can encode and decode in the sendrecv line
16:51:57 <dom> ... avoids the long laundry list of profiles
16:52:12 <dom> ... it feels like the simplest
16:52:16 <dom> ack youenn
16:52:33 <dom> youenn: +1 to proposal A as the default behavior
16:52:53 <dom> ... I'm OK with having a different API to include sendonly codecs
16:53:04 <dom> ... maybe setCodecPreferences could be used to extend the default?
16:53:31 <dom> Henrik: it does make sense with a conservative place and expand with a use case for this
16:54:30 <Sameer> Sameer has joined #webrtc
16:54:34 <dom> jib: I like B - the only issue is if the other side removes the supported codec
16:54:49 <markafoltz> markafoltz has joined #webrtc
16:54:50 <dom> ... I would like to get away from having the directionality matter so much
16:55:12 <dom> ... I'm not opposed to A, but I don't see that much problem with B
16:55:30 <dom> Henrik: with B, you say what you prefer to receive, not what you prefer to send
16:56:05 <dom> fluffy: say you send H264 and H265
16:56:30 <dom> ... the other party may want to remove H264 to select only the most recent codec
16:56:44 <dom> ... proposal B cannot be expressed reliably in O/A SDP
16:57:13 <dom> Henrik: the only path to removing H264 would be via a unidirectional transceiver then?
16:57:37 <dom> Fluffy: yes - I don't see how B, C and D would interop with O/A SDP
16:58:05 <dom> ... proposal B feels like it relies on magic out of band info
16:58:10 <dom> Bernard: the AVT Core WG gave the same feedback
16:58:17 <hta> q?
16:58:31 <fluffy> ack fluffy
16:58:34 <dom> ack jib
16:58:52 <dom> Henrik: proposal A may be the path of least confusion
16:58:59 <dom> HTA: I agree A is the least confusing
16:59:12 <dom> ... do we care about what happen when you change the direction of a transceiver?
16:59:20 <dom> jib: that's what I wanted to avoid
16:59:28 <markafoltz_> markafoltz_ has joined #webrtc
17:00:05 <dom> HTA: once you have allocated the payload type on the transport, that payload cannot be changed per RTP rules
17:00:15 <markafoltz_> markafoltz_ has left #webrtc
17:00:25 <markafoltz_> markafoltz_ has joined #webrtc
17:00:44 <dom> Bernard: changing direction and with a different level id doesn't require a new payload type, but a different profile does IIRC
17:01:27 <dom> HTA: so if you have sendonly set to H264 High, and change to sendrecv and can only support constrained, you either to allocate a new payload type or you re-use the payload type and hope it doesn't break
17:02:04 <dom> Henrik: is there any reason not to use a new payload type since you have to renegotiate any way?
17:02:49 <dom> HTA: with my chair hat on, I see convergence towards proposal A, with more fancy options available through unidrectional transceivers
17:03:00 <dom> PROPOSED: Consensus to use approach Proposal A
17:03:36 <dom> RESOLVED: Consensus to use approach Proposal A
17:03:58 <dom> Orphis: backwards-compatible?
17:04:33 <dom> Henrik: it's conservative so should be good, but it may that people have been relying on having all codecs sent to sendrecv?
17:05:06 <dom> JIB: I think proposal B likely is closer to what current browser need
17:05:10 <dom> HTA: we will need tests
17:05:15 <Orphis> Orphis has joined #webrtc
17:05:17 <dom> Dom: and real world compatibility checks
17:05:22 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/ IceTransport Extensions
17:05:22 <dom> SUbtopic: Issue #209 App control over ICE checks
17:05:22 <dom> [slide 31]
17:05:41 <RahulS> RahulS has joined #webrtc
17:06:27 <dom> [slide 32]
17:08:20 <dom> [slide 33]
17:10:06 <baboba> +q
17:11:08 <jib> q+
17:11:26 <dom> Bernard: once you've nominated with traditional ICE, you can't do this
17:11:40 <dom> sameer: we have an API that allows to cancel nomination
17:11:47 <dom> ... and another one to select a different pair
17:11:59 <dom> ... we could switch across different pairs during a session
17:12:16 <dom> Bernard: "canceling" a nomination normally happens through an ICE restart
17:12:27 <dom> sameer: once nomination has come through, you would do an ICE restart
17:12:49 <dom> Peter: one way to think about this is that it allows to do better ICE
17:13:03 <dom> ... even without the renomination attribute
17:13:06 <fluffy> q+
17:13:14 <dom> Bernard: pre-nomination, this makes sense
17:13:18 <dom> ack baboba
17:13:25 <resakai> resakai has joined #webrtc
17:13:39 <dom> ack hta
17:13:49 <dom> hta: nomination was probably a bad idea in this context
17:14:03 <peter> q+
17:14:14 <dom> jib: it seems a bit hackish to defer nomination for ever - if that's indeed the idea?
17:14:16 <steely-glint> q+
17:14:42 <dom> ... why is restart ICE prohibitive, since it allows seamless continuity
17:14:54 <dom> Sameer: restart requires redoing checks, etc
17:15:18 <dom> jib: but given that this is tied to a change in situation, wouldn't it better to do a restart?
17:15:37 <baboba> +q
17:15:41 <dom> sameer: unless a new network has come up, this would be a lot faster and lighter than a full restart
17:15:42 <dom> ack jib
17:15:44 <dom> ack fluffy
17:15:45 <jib> q-
17:16:11 <dom> fluffy: is it more to save power (not wake up the cellular radio) or to save bandwidth?
17:16:14 <jib> q+
17:16:25 <dom> ... I'm not seeing much saving here
17:17:07 <hta> q?
17:17:12 <dom> Sameer: preventing ICE checks is mostly about saving power with the radio (since waking it up has a lasting effect)
17:17:34 <youenn> youenn has joined #webrtc
17:17:47 <dom> ... it takes 15 to 20s to go back to low power
17:18:11 <dom> fluffy: the consent checks is to limit the DDOS attack window - so there is a trade-off here
17:18:42 <dom> ... an ICE agent could remember previous successful checks to accelerate ICE start
17:19:02 <dom> ... a number of apps rely on nomination happening
17:19:05 <fluffy> q-
17:19:16 <dom> baboba: we now have APIs in the browser to minimize power usage
17:19:34 <dom> ... they give an event to tell you when you're already in high power state to avoid waking up the modem
17:19:54 <dom> ... ICE mobility allows to keep connectivity no matter what by doing restart in the background
17:20:18 <hta> q+
17:20:18 <dom> ... I'm concerned with the power management issue if you don't have the right event structure to tell you when to do the ICE checks
17:20:38 <jesup> jesup has joined #webrtc
17:20:54 <dom> sameer: this doesn't necessarily block you to use other approaches for more efficient process
17:21:22 <dom> Youenn: Bernard, are you saying the UA would be better positioned to optimize this? I agree with that
17:21:26 <dom> jib: +1
17:21:31 <dom> ack jib
17:21:53 <dom> ... it would be best if the JS could simply instruct the browser to use the lightweight approach instead of having to deal with them
17:21:56 <dom> ack baboba
17:22:13 <dom> Sameer: we could have configurations that let the app guide the UA ICE Agent
17:22:17 <jib> q-
17:22:21 <dom> ... but it's not clear how many options this would require
17:22:39 <peter> I don't think it's possible to express everyting an app would want to do as a configuration.
17:22:43 <dom> ... this proposal is simpler than having lots of configuration options that need to be consistent with each other
17:23:05 <dom> Peter: these are not theoretical things - they are being used in mobile apps, and libwebrtc supports these techniques
17:23:17 <dom> ... right now, this can't be done in Web apps
17:23:29 <youenn> +q
17:23:34 <peter> -=
17:23:35 <peter> -q
17:23:39 <dom> TimP: on the nomination front, getting rid of it loses some security strength
17:23:47 <dom> ack steely-glint
17:24:08 <dom> ... DDOS against DTLS is prevented by the current nomination behavior
17:24:37 <dom> ... I do see the necessity for this sort of API: you can't totally leave it to the UA because the UA won't necessarily make the right decision
17:25:03 <dom> ... e.g. retaining connectivity is seen as the end goal, when in fact you might prefer a bit of a gap and stay on the much quicker network
17:25:26 <peter> Just because the JS *can* disable nomination doesn't mean it has to.
17:25:27 <steely-glint> q-
17:25:42 <peter> And if we want to add support for renomination, we can.  It's already widely implemented.
17:25:54 <dom> sameer: it's still up to the app to decide to remove nominations in this proposal
17:26:04 <dom> ack hta
17:26:56 <dom> hta: I presented NICEr to IETF in July 21; the feedback was that the browser would not know the right thing to do
17:27:27 <mt> mt has joined #webrtc
17:27:30 <dom> ... we've had multiple discussions about the value of doing things in the app rather than the browser - let's not revisit it
17:28:05 <dom> youenn: re mobile apps doing that - which API are they using? is this similar to what is being proposed? what algorithm/input are they using to make that choice?
17:28:13 <hta> https://www.ietf.org/archive/id/draft-oreland-dispatch-ice-nicer-00.html
17:28:28 <dom> ... if my laptop is connecting through my phone, the Web page wouldn't know that and might make choices that would be poor
17:28:39 <dom> ... and we will never be in a position to expose this to a Web page
17:29:07 <dom> Peter: they're doing what Sameer is describing with a backup candidate pair, by keeping the backup with checks at a lower rate
17:29:39 <dom> ... you're right that we're not exposing the nature of the connection to Web pages, which indeed is an issue for parity with native apps
17:29:40 <dom> q?
17:29:42 <dom> ack youenn
17:30:01 <hta> q+
17:30:29 <dom> youenn: would webrtc stats allow to make a good choice?
17:30:43 <dom> sameer: it's not only the type of network interface
17:30:45 <dom> ack hta
17:31:30 <dom> hta: one scenario: you're talking on the phone via a WebRTC app, and getting close to a known wifi network, with a coverage gap
17:31:52 <dom> ... the signal you need to make this happen smoothly is the quality of the connection, not their type
17:32:59 <dom> RRSAgent, draft minutes
17:33:00 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/24-webrtc-minutes.html dom
17:33:51 <fluffy4> fluffy4 has joined #webrtc
17:57:55 <dom> dom has joined #webrtc
17:58:49 <dom> Fwiw, there is a massive power outage in the venue, so we won't be able to restart on time. No clear ETA to power resumption atm
18:02:26 <henbos> henbos has joined #webrtc
18:04:09 <Orphis> I've relayed the info on the Zoom chat
18:04:32 <hta> hta has joined #webrtc
18:05:15 <hta> The resident chair had decided that the break is extended until the hotel has power again.
18:05:20 <jib> jib has joined #webrtc
18:05:33 <hta> Apparently the whole block is out.
18:16:03 <dom> dom has joined #webrtc
18:20:06 <fluffy4> https://www.meetecho.com/blog/moq-webrtc/
18:42:40 <fluffy> fluffy has joined #webrtc
18:42:46 <fluffy> test
18:44:04 <RahulS> RahulS has joined #webrtc
18:47:06 <hta> hta has joined #webrtc
18:49:46 <hta> Rest of session now officially cancelled. We will resume the agenda at a later meeting. Sorry about that!
18:49:51 <PeterThatcher> PeterThatcher has joined #webrtc
18:54:03 <fluffy> Any ETA on power coming back ?
18:56:58 <dom> dom has joined #webrtc
19:09:29 <renki> renki has joined #webrtc
19:57:19 <Zakim> Zakim has left #webrtc
19:58:19 <markafoltz> markafoltz has joined #webrtc
20:04:03 <PeterThatcher> PeterThatcher has joined #webrtc
20:10:20 <joachimr> joachimr has joined #webrtc
20:17:45 <dom> dom has joined #webrtc
20:28:31 <youenn> youenn has joined #webrtc
20:38:06 <markafoltz> markafoltz has joined #webrtc
20:46:45 <dom> RRSAgent, bye
20:46:45 <RRSAgent> I see no action items