Meeting minutes
Recording: https://
Slideset: https://
<henbos> Hello world
State of the WG 🎞︎
<fluffy> I'm actually lost on how we get in the speaker Q.
<peter> "raise hand"?
<peter> You can use "raise hand" on zoom? I thought the slide said IRC was required.
<fluffy> thx
jib: Firefox 132 is now shipping (in nightly) with a more private enumerateDevices, an important step towards moving forward to Rec
… progress on implementing in mediacapture-transform in FF and Safari
… and some progress in webrtc-trancsform as well
Updating the W3C Recommendation 🎞︎
<youenn> youenn: heavyweight process. Why not simplify the process?
<youenn> dom: some amendments are not implemented twice, that is the main filter for amendments that can move forward and other amendments.
<youenn> youenn: how do we tracks not fully implemented amendments
<youenn> dom: there is a page with the list.
<youenn> dom: going through the list of amendments that can move forward.
<youenn> fluffy: are we tracking changes that could trigger backward incompatibility?
<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.
<youenn> bernard: for some issues, backward compatibility concerns have been raised (which number???)
Youenn: for any new amendment for behavior, we should file engine bugs and keep link in the github issues
<fluffy> which browsers should we file bugs on ?
Dom: this could be even enforced automatically through the amendment process
Youenn: maybe let's first ask editors to keep that in mind
HTA: WPT can attach bugs to failing tests
<fluffy> Huge THANK YOU to Dom
HTA: any objection to proceed with that plan?
RESOLUTION: Proceed with publishing proposed amendments as described
Codec Issues 🎞︎
Making Codecs Transceiver-specific 🎞︎
<peter> Just don't use "sendrecv" :)
<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...
Bernard: the question of what a codec means has been raised; e.g. for H265 not all profiles are necessarily meant to be supported
Henrik: in terms of negotiating payload types, this is a side problem - that I'm ignoring for now
Peter: what about saying "don't use sendrecv"?
fluffy: why would you mark something as sendrecv if you can't send & receive?
bernard: this may also lead to offering wrong profiles
fluffy: what is the motivation for this?
henrik: we have been living so far in a world where most codecs were sendrecv
fluffy: the codecs are almost never symetric
henrik: proposal A is the least powerful option, and may not be backwards compatible given what I hear about profiles
… I would lean towards B among A, B, C
… D is about relaxing the RFC expectations
Harald: the RFC language is ambiguous - "indicate codecs" can be interpreted in 2 ways
… the codec number is included in the m-line, or it is included in an rtpmap line
… 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
… but SDP has been unclear about allowing to do this
Henrik: I like it for this reason, but there is no API to check the rtpmap line
… but it still ends up excluding anything not in the preference list
Peter: my proposal E: if you want recvonky codecs, you create a recvonly transceiver
Henrik: that's proposal A - it avoids the footgun
Bernard: I also like A - it gives significant clarity
… e.g. going through profiles, you'd indicate the highest profile you can encode and decode in the sendrecv line
… avoids the long laundry list of profiles
… it feels like the simplest
youenn: +1 to proposal A as the default behavior
… I'm OK with having a different API to include sendonly codecs
… maybe setCodecPreferences could be used to extend the default?
Henrik: it does make sense with a conservative place and expand with a use case for this
jib: I like B - the only issue is if the other side removes the supported codec
… I would like to get away from having the directionality matter so much
… I'm not opposed to A, but I don't see that much problem with B
Henrik: with B, you say what you prefer to receive, not what you prefer to send
fluffy: say you send H264 and H265
… the other party may want to remove H264 to select only the most recent codec
… proposal B cannot be expressed reliably in O/A SDP
Henrik: the only path to removing H264 would be via a unidirectional transceiver then?
Fluffy: yes - I don't see how B, C and D would interop with O/A SDP
… proposal B feels like it relies on magic out of band info
Bernard: the AVT Core WG gave the same feedback
Henrik: proposal A may be the path of least confusion
HTA: I agree A is the least confusing
… do we care about what happen when you change the direction of a transceiver?
jib: that's what I wanted to avoid
HTA: once you have allocated the payload type on the transport, that payload cannot be changed per RTP rules
Bernard: changing direction and with a different level id doesn't require a new payload type, but a different profile does IIRC
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
Henrik: is there any reason not to use a new payload type since you have to renegotiate any way?
HTA: with my chair hat on, I see convergence towards proposal A, with more fancy options available through unidrectional transceivers
PROPOSED: Consensus to use approach Proposal A
RESOLUTION: Consensus to use approach Proposal A
Orphis: backwards-compatible?
Henrik: it's conservative so should be good, but it may that people have been relying on having all codecs sent to sendrecv?
JIB: I think proposal B likely is closer to what current browser need
HTA: we will need tests
Dom: and real world compatibility checks
IceTransport Extensions 🎞︎
Issue #209 App control over ICE checks 🎞︎
Bernard: once you've nominated with traditional ICE, you can't do this
sameer: we have an API that allows to cancel nomination
… and another one to select a different pair
… we could switch across different pairs during a session
Bernard: "canceling" a nomination normally happens through an ICE restart
sameer: once nomination has come through, you would do an ICE restart
Peter: one way to think about this is that it allows to do better ICE
… even without the renomination attribute
Bernard: pre-nomination, this makes sense
hta: nomination was probably a bad idea in this context
jib: it seems a bit hackish to defer nomination for ever - if that's indeed the idea?
… why is restart ICE prohibitive, since it allows seamless continuity
Sameer: restart requires redoing checks, etc
jib: but given that this is tied to a change in situation, wouldn't it better to do a restart?
sameer: unless a new network has come up, this would be a lot faster and lighter than a full restart
fluffy: is it more to save power (not wake up the cellular radio) or to save bandwidth?
… I'm not seeing much saving here
Sameer: preventing ICE checks is mostly about saving power with the radio (since waking it up has a lasting effect)
… it takes 15 to 20s to go back to low power
fluffy: the consent checks is to limit the DDOS attack window - so there is a trade-off here
… an ICE agent could remember previous successful checks to accelerate ICE start
… a number of apps rely on nomination happening
baboba: we now have APIs in the browser to minimize power usage
… they give an event to tell you when you're already in high power state to avoid waking up the modem
… ICE mobility allows to keep connectivity no matter what by doing restart in the background
… 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
sameer: this doesn't necessarily block you to use other approaches for more efficient process
Youenn: Bernard, are you saying the UA would be better positioned to optimize this? I agree with that
jib: +1
… it would be best if the JS could simply instruct the browser to use the lightweight approach instead of having to deal with them
Sameer: we could have configurations that let the app guide the UA ICE Agent
… but it's not clear how many options this would require
<peter> I don't think it's possible to express everyting an app would want to do as a configuration.
Sameer: this proposal is simpler than having lots of configuration options that need to be consistent with each other
Peter: these are not theoretical things - they are being used in mobile apps, and libwebrtc supports these techniques
… right now, this can't be done in Web apps
<peter> -=
TimP: on the nomination front, getting rid of it loses some security strength
… DDOS against DTLS is prevented by the current nomination behavior
… 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
… 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
<peter> Just because the JS *can* disable nomination doesn't mean it has to.
<peter> And if we want to add support for renomination, we can. It's already widely implemented.
sameer: it's still up to the app to decide to remove nominations in this proposal
hta: I presented NICEr to IETF in July 21; the feedback was that the browser would not know the right thing to do
… we've had multiple discussions about the value of doing things in the app rather than the browser - let's not revisit it
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?
<hta> https://
youenn: if my laptop is connecting through my phone, the Web page wouldn't know that and might make choices that would be poor
… and we will never be in a position to expose this to a Web page
Peter: they're doing what Sameer is describing with a backup candidate pair, by keeping the backup with checks at a lower rate
… 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
youenn: would webrtc stats allow to make a good choice?
sameer: it's not only the type of network interface
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
… the signal you need to make this happen smoothly is the quality of the connection, not their type
[Meeting adjourned early due to power outage at the venue]