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

[Christer Holmberg <[e-mail]>]

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