IRC log of webrtc on 2024-09-24

Timestamps are in UTC.

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