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

I agree with Roman.

On Wed, Mar 20, 2024 at 12:59 PM Roman Shpount <roman@telurix.com> wrote:

> Bernard,
>
> sCP affects which codecs can be sent on both send-only and sendrecv
> m-lines. Specifically, it proposes which codecs are allowed and their
> relative preference to the answering party. The answering party decides
> which codecs should be left in the list based on its preferences and
> supported codecs. So, during the offer, it controls what is being offered
> (which does not guarantee that it is what is being used), and the answering
> party decides. The m=line direction is irrelevant.
> _____________
> Roman Shpount
>
>
> On Wed, Mar 20, 2024 at 1:09 PM Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
>
>> The problem is that for a send-only m-line, sCP does affect what codecs
>> can be sent.
>>
>> On Mar 20, 2024, at 02:46, Christer Holmberg <christer.holmberg=
>> 40ericsson.com@dmarc.ietf.org> wrote:
>>
>> 
>>
>> Hi,
>>
>>
>>
>> In general, I don’t think the spec should say whether something affects
>> an implementation or not. How do we know what affects what in an
>> implementation?
>>
>>
>>
>> If we want to clarify something, we could say something like “sCP is not
>> used to indicate which codec an implementation shall send”.
>>
>>
>>
>> Also, maybe the statement that sCP only affects what an implementation
>> wants to receive should be in the first sentence of the section? Now the
>> sentence only talks about “codec preference”, which I assume can cause
>> confusion.
>>
>>
>>
>> Finally, if there is text somewhere that DOES define how the
>> implementation shall decide what codec to send, there could be a reference.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>> *From:* rtcweb <rtcweb-bounces@ietf.org> *On Behalf Of *Justin Uberti
>> *Sent:* Wednesday, 20 March 2024 0.32
>> *To:* Murray S. Kucherawy <superuser@gmail.com>
>> *Cc:* Harald Alvestrand <hta@google.com>; RTCWeb IETF <rtcweb@ietf.org>;
>> Henrik Boström <hbos@google.com>
>> *Subject:* Re: [rtcweb] JSEPbis: Questions about send-only/recv-only
>> codecs and Section 4.2.6
>>
>>
>>
>> Some people who received this message don't often get email from
>> justin=40fixie.ai@dmarc.ietf.org. Learn why this is important
>> <https://aka.ms/LearnAboutSenderIdentification>
>>
>> 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 <superuser@gmail.com>
>> wrote:
>>
>> On Mon, Mar 4, 2024 at 3:57 PM Justin Uberti <justin=
>> 40fixie.ai@dmarc.ietf.org> 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
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>