Modify the codec description model to ease describing changes about webrtc-pc

[fippo]

The current situation is indeed not good. When adding codecs that are rarely used like H264 with 444 they get added to the SDP, consuming a payload type and increase the size of the SDP (and remember that we had a comparison between the WebRTC SDP and the Empire State building in one slide deck).

setCodecPreferences can be (somewhat) used to limit this but it requires action.

[alvestrand]

If we allow setParameters() to enable a disabled codec (https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-codec), the only missing piece is discoverability.
And in simulcast, we deferred discoverability to MediaCapabilities (decodingInfo with "webrtc" - ask, and you shall learn). If we were to address the bug asking for CodecCapability, perhaps we have all the pieces?

[alvestrand]

I'll ask for this issue to be discussed at the February WG meeting, since I feel that doing this will make resolving our other issues easier, but want to have WG consensus on the approach before preparing the PR.

[henbos]

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 (#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 #2932. I also think that Fippo's PR needs to remove this sentence from createAnswer. Does that make sense to everyone or am I still confused?

[dontcallmedom-bot]

This issue was discussed in WebRTC February 2024 meeting – 20 February 2024 (Modify the codec description model to ease describing changes #2925 #2935)