Draft: draft-ietf-rtcweb-jsep

Commentary: 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 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 . 
  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
Paragraph (version B):
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.
Paragraph (version A):
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
transceiver.
Paragraph (version B):
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
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.
Paragraph (version A):
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
not present in the offer.
Paragraph (version B):
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
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.