Re: [rtcweb] JSEPbis: Questions about send-only/recv-only codecs and Section 4.2.6

[Justin Uberti <[e-mail]>]

I don't think any changes are needed in RFC8829bis, I believe the text in S
4.2.6 is sufficient.

If necessary though we could expound on the sentence in 4.2.6 that says
"Note that setCodecPreferences does not directly affect
   which codec the implementation decides to send" to make the intent
clearer.

On Mon, Mar 18, 2024 at 4:54 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Mon, Mar 4, 2024 at 3:57 PM Justin Uberti <justin=
> [e-mail]> wrote:
>
>> The idea behind the text in red is an explicit callout to the fact that
>> the implementation may decide to use other mechanisms (e.g.,
>> RtcRtpSender.setParameters, CPU or bandwidth limitations, etc) to decide
>> exactly what should be sent over the wire.
>>
>> Also, this API is intended to directly influence signaling, i.e., the set
>> of codecs that are offered. It is not intended to directly control
>> RtpSender settings.
>>
>> I agree with the point that the operation here may seem a bit weird for a
>> sendonly m= line. That said, I think it is entirely consistent with RFC
>> 3264 S 5.1, where a) what is offered is primarily intended as a guide for
>> what the answerer will actually send and b) the answerer may choose to send
>> whatever it wants as long as it uses a format from the offer.
>>
>> I think keeping sCP focused on what goes into the actual offer will make
>> it easier to reason about this API.
>>
>
> Are there any required changes to RFC8829bis, which is in AUTH48?
>
> -MSK
>