- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Feb 2024 10:36:01 +0000
- To: public-webrtc-logs@w3.org
Moving the check from the checking a global state to checking a sender/receiver state, in order to unblock changing sender/receiver capabilities, makes sense to me. > If a codec in a remote offer or answer is on the supported list, but “enabled” is false, “enabled” is set to true. This ensures that the codec is included in subsequent offers and answers. (Note: This is the only part of this reimagining that might include a behavior change, but we suspect that this is the way current implementations behave anyway.) I think we need to do this for unidirectional codecs anyway? Hopefully we already do it > The final steps to create an offer or answer is not influenced by the current negotiation state, but there is a NOTE in the setCodecPreferences section suggesting that answers should only have codecs that appear in the offer. I think this NOTE is wrong and should be deleted (https://github.com/w3c/webrtc-pc/issues/2933). I also think there is some major confusion about `a=rtpmap` versus preferences (at least for me, but maybe it's crystal clear for everyone else), so I filed https://github.com/w3c/webrtc-pc/issues/2932. I also think that Fippo's PR needs to [remove this sentence from createAnswer](https://github.com/w3c/webrtc-pc/pull/2926/files#r1475860795). Does that make sense to everyone or am I still confused? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2925#issuecomment-1923530832 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 February 2024 10:36:03 UTC