- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Apr 2024 19:04:39 +0000
- To: public-webrtc@w3.org
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc: == setCodecPreferences should trigger negotiationneeded == [setCodecPreferences](https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-setcodecpreferences) _"overrides the default receive codec preferences used by the [user agent](https://w3c.github.io/webrtc-pc/#dfn-user-agent)"_, but negotiation is needed before changes affect transmission. Example: - https://jsfiddle.net/jib1/8mosy476 changes codecs mid-stream with `setCodecPreferences`ยน Oddly, `setCodecPreferences` doesn't trigger `negotiationneeded`, so the fiddle has to call its own `pc1.onnegotiationneeded()` explicitly as a workaround. Unfortunately, this hack risks introducing intermittent timing issues with other negotiation needs. **Proposal:** make `setCodecPreferences` trigger `negotiationneeded` as needed. The _"as needed"_ part might require some judgement: it's sometimes desirable to call `setCodecPreferences` in `"have-remote-offer"` just in time to affect an answer. Since answers can carry just as much weight as offers (arguably more), it might be undesirable to trigger what would be a reverse-role negotiation in this case (once it returns to `"stable"`). We'd need to work out these details in the [check if negotiation is needed](https://w3c.github.io/webrtc-pc/#dfn-check-if-negotiation-is-needed) algorithm. Language similar to how we handle direction there might work (i.e. consider a match in the local description satisfactory regardless of whether it's an offer or an answer). --- <sub>1. Works in Chrome/Edge and Safari right now. Landing soon in Firefox 127.</sub> Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2964 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 19 April 2024 19:04:39 UTC