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

[Taylor Brandstetter <[e-mail]>]

Hi Jonathan,

This is why we have setCodecPreferences. There are certainly use cases
where you *do* want to list codecs in browser preference order. And there
are cases where you don't. setCodecPreferences lets the application
developer decide which is appropriate.

Regards,
-Taylor

On Fri, Oct 27, 2017 at 2:14 PM, Ted Hardie <[e-mail]> wrote:

> 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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>