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

[Harald Alvestrand <[e-mail]>]

Den 27. okt. 2017 22:05, skrev Jonathan Lennox:
> 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?

I don't read it like that.

The answer consists of:

- The offer's listed codecs that are also supported by the answerer,
possibly rearranged according to codec preference
- The answerer's supported codecs that were not listed in the offer.

These aren't "remotely-unsupported", they are unlisted by the offerer.

If they're really not supported by the offerer, adding them will have no
effect.

If they're supported by the offerer but the offerer chose not to list
them (might happen for instance if one is an inferior mode of a
supported codec, which the offerer did not think was worth mentioning),
listing them before listed codecs would be overriding a strongly stated
preference by the offerer.

I like the current logic.


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

If the SFU offers A, B to participants 2 and 3, and both 2 and 3 prefer
B, they will answer B, A based on local codec preference.

It will have to ask, but is that a big deal?

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

I don't have a strong preference here, but do have a strong preference
against holding up the spec if this is the biggest issue left.

> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>