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

[Christer Holmberg <[e-mail]>]

Hi,

I also agree. sCP impacts what CAN be sent, because it impacts the offer. What WILL be sent then depends on the outcome of the offer/answer exchange, and (I assume) implementations. As far as I know, from a standards perspective there is no mandate to send the codec with the highest preference in an offer/answer. But, perhaps that is what implementations do?

Regards,

Christer


> -----Original Message-----
> From: Justin Uberti <[e-mail]>
> Sent: Thursday, 21 March 2024 7.39
> To: Roman Shpount <[e-mail]>
> Cc: Bernard Aboba <[e-mail]>; Christer Holmberg
> <[e-mail]>; RTCWeb IETF <[e-mail]>; Henrik
> Boström <[e-mail]>; Harald Alvestrand <[e-mail]>
> Subject: 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 <[e-mail]
> <mailto:[e-mail]> > 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
> <[e-mail] <mailto:[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]
> <mailto:[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]
> <mailto:[e-mail]> > On Behalf Of Justin Uberti
> 			Sent: Wednesday, 20 March 2024 0.32
> 			To: Murray S. Kucherawy <[e-mail]
> <mailto:[e-mail]> >
> 			Cc: Harald Alvestrand <[e-mail]
> <mailto:[e-mail]> >; RTCWeb IETF <[e-mail]
> <mailto:[e-mail]> >; Henrik Boström <[e-mail]
> <mailto:[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] <mailto: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] <mailto:[e-mail]> > wrote:
> 
> 				On Mon, Mar 4, 2024 at 3:57 PM Justin Uberti
> <justin=[e-mail] <mailto:[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] <mailto:[e-mail]>
> 			https://www.ietf.org/mailman/listinfo/rtcweb
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Frtcweb&data=05%7C02%7Cchrister.holm
> berg%40ericsson.com%7Cfa5d70171771406ec8ac08dc49694d5c%7C92e84ce
> bfbfd47abbe52080c6b87953f%7C0%7C0%7C638465963819078210%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5x3iil8JuQb2Rx%2FGLL5
> mhKzLLNhdjopeAaHVIC3PAVQ%3D&reserved=0>
> 
> 
> 		_______________________________________________
> 		rtcweb mailing list
> 		[e-mail] <mailto:[e-mail]>
> 		https://www.ietf.org/mailman/listinfo/rtcweb
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Frtcweb&data=05%7C02%7Cchrister.holm
> berg%40ericsson.com%7Cfa5d70171771406ec8ac08dc49694d5c%7C92e84ce
> bfbfd47abbe52080c6b87953f%7C0%7C0%7C638465963819088277%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k4nIYCeV5CE%2BCvcWc
> l6ihw85VamTOb1kwPH1ESy8tes%3D&reserved=0>
>