Change:
Fixes issue .
Note that I made this a MAY and not a MUST, because the only precedent for a MUST in codec selection is with regards to the mandatory codecs.
This seems like it still needs some more work, as we discussed earlier.
I added some more informative text about non-JSEP endpoints. Does this address your concerns Ekr? There are still some questions about when (if ever) a JSEP endpoint is allowed to include previously discarded codecs in an offer (issue ), but this PR should at least address issue .
Browser offer MCU, VP9, and VP10. MCU answers with VP10. Offer / answer completes. Later the MCU offers VP9 to browser on m-line that was currently use VP10. What does the browser do? A strict reading of spec might suggest that since MCU only offered VP9, and current is VP10, the m-line should be rejected. Do we need to change this ? Is it OK for browser to respond with VP9.
Previously I've heard people say "the non-JSEP endpoint can do whatever it wants with codecs." For example, in the thread for issue .
It is definitely OK for the browser to accept the VP9 in the updated offer and I would go further and say that it must accept VP9 in such an updated offer if it is capable of doing so. The spec should make it clear that browsers MUST accept such codec changes in updated offers.
If we solve this, should resolve.
Originally raised by Magnus. If any payload type could map to more than one RtpReceiver, map to the RtpReceiver whose m= section appears earliest in the local description. I think this is a bad advice. I think it should say that if this is the case, PT should not be used to try to determine which m= section it belongs to. I think wrongly attributing a packet is worse than dropping it in cases where the information is incomplete. This rule can result in that one associate an SSRC with the wrong m= section.
there is another bug on this too - I agree we could change this
Obsoleted by events - moved to BUNDLE
With changes above

Discussion:
media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. <ins> The media formats in the answer MAY include codecs present in the offer that were discarded in a previous offer/answer exchange. This is necessary for compatibility with third- party call control and SIP use cases. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf- rtcweb-audio(see Section 3) and I-D.ietf-rtcweb-video(see

The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include codecs present in the most recent answer which have not been excluded by the codec preferences of the associated <del> transceiver. </del> <ins> transceiver.  Note that non-JSEP endpoints are not subject to these restrictions, and might offer media formats that were not present in the most recent answer, as specified in RFC3264, Section 8.  Therefore, JSEP endpoints MUST be prepared to receive such offers. </ins> The media formats on the m= line MUST be generated in the same order as in the current local description.

If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or <del> not present in the offer. </del> <ins> not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP endpoints MUST be prepared to receive such answers. </ins> Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in I-D.ietf-