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

[Ted Hardie <[e-mail]>]

Hi Jonathan,

On Fri, Oct 27, 2017 at 1:05 PM, Jonathan Lennox <[e-mail]> wrote:

> 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).
>

So, we're currently past WG last call and IETF last call, with the draft in
IESG evaluation.  This proposal appears to change a method that has been
agreed through all of those process and which produces a correct answer.
While it may bee mildly suboptimal for the duration of the conference in
the case above, it works and simplifies the conference behavior by
presuming no re-offer occurs until a participant 4 arrives who does only B
(If participant 1 has left, the conference can then re-offer codec B to 2
and 3).

While I appreciate the care you're going through with this, I don't believe
that this trade-off rises to the level of concern that would warrant
re-opening the question.

regards,

Ted