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

[Christer Holmberg <[e-mail]>]

Hi,

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

A few things to keep in mind, if adding codec X in the answer, when X was
not in the offer:

1) The answerer needs to be prepared to receive media using codec X, but
the answerer cannot send media using codec X.
2) If the offerer does support X (even if it did not include it in the
offer), the offerer cannot use it if using it would require providing
codec related SEND parameters.

Regards,

Christer