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

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
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=
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Justin Uberti
> *Sent:* Wednesday, 20 March 2024 0.32
> *To:* Murray S. Kucherawy <[e-mail]>
> *Cc:* Harald Alvestrand <[e-mail]>; RTCWeb IETF <[e-mail]>;
> Henrik Boström <[e-mail]>
> *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=[e-mail]. 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 <[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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>