Re: [rtcweb] JSEP: codecs in answer: ordering (was codecs in answer: MUST vs. MAY)

[Jonathan Lennox <[e-mail]>]

Another question about JSEP’s codec answer rules.

The spec currently says:
>>    o  Otherwise, the media formats on the m= line MUST be generated in
>>       the same order as those offered in the current remote description,
>>       excluding any currently unsupported formats.  Any currently
>>       available media formats that are not present in the current remote
>>       description MUST be added after all existing formats.
>> 
>> This is what you do if codec preferences are not set (keep the order, add any new ones to the end)

Why are remotely-unsupported codecs added at the end of the list, rather than just listing all locally-supported codecs in the browser’s preference order?

My concern is in an SFU conferencing scenario.  Consider the following:

* Participant 1 joins a conference.  It supports only codec A.
* Participant 2 joins the conference.  It supports codecs A and B, but prefers B.  Since the conference can only do A, if the offer/answer exchange goes SFU->Participant, the participant’s answer must list its codecs as A, B.
* Participant 3 joins the conference.  It is the same as Participant 2, preferring B to A.

If participant 1 leaves, the SFU can re-offer to participants 2 and 3; but as far as it knows, everyone prefers A to B, so the conference can end up in a scenario where everyone’s using a less-preferred codec.

I would suggest that instead, the browser’s codec preference order always be sent as-is in an answer (unless overridden by the app with setCodecPreferences).  This also has the benefit of aligning the behavior with and without app codec preferences, rather than having two separate behaviors (where the order is fixed if the app has set codec preferences, and mirrored otherwise).