setCodecPreferences should trigger negotiationneeded about webrtc-pc

[jan-ivar]

Concern was raised in yesterday's meeting over the web compatibility of introducing this change in behavior now.

Let's examine cases where existing websites might feature-detect and call setCodecPreferences in Chromium and Safari and their possibility of breakage.

No breakage:

• calling it in "stable" alongside other methods like addTrack/addTransceiver/setStreams/direction/createDataChannel
• calling it in "have-remote-offer" as part of answering
• not using a negotiationneeded event listener to negotiate
• using sLD() without arguments to negotiate

Breakage of intent:

• calling it with the intent for it to take effect in a much later negotiation, or not at all
  • breakage = updates too soon (seems mild), or updates when it shouldn't (seems esoteric/rare)

Negotiation completes but logs an error:

• calling it in "stable" without any other methods (using sLD(offerFromCreateOffer) to negotiate)
• calling it in "have-remote-offer" after answering

Negotiation breaks:

• I can't think of any cases, though it would require custom code in negotiationneeded event handler (or double code) that requires tight control of when it can be called (which seems unlikely to me)
• Maybe some SFU cases I haven't thought about?
• Applications explicitly written to terminate on any unexpected error logged (doctor it hurts when I do this)

Happy to field questions on any of these.

[alvestrand]

It's a stretch of the imagination, but one can imagine a setup like this (equivalent to your "breakage of intent" setup):

• Negotiate an initial connection (DC only, for instance)
• set up a negotiationneeded handler that does an immediate O/A
• start preparing for the "real" negotiation
• • call SetCodecPreferences
• • ask for camera/microphone permission
• • add tracks when permission is given
• based on the onnegotiationneeded from addTracks, negotiate the final config based on the negotiationneeded in "add tracks"

The change will then cause an extra negotiation without the media tracks, which may or may not have any bad effects.
The fix would be "move the handler setup to just before the addTrack". But it is a change in behavior.

[jan-ivar]

• • call SetCodecPreferences
• • ask for camera/microphone permission
• • add tracks when permission is given

This order seems unlikely, since there's no transceiver to call setCodecPreferences on ahead of addTrack.