(no subject)

> On 14 Jan 2020, at 09:02, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 
> 
> On 1/13/20 10:19 PM, Bernard Aboba wrote:
>> Depending on the direction, we could potentially be looking at header extensions that would be sent and received, only sent or only received (inactive header extensions aren't included in the SDP).   So if we were to do this at the sender/receiver level, we would need two APIs, RTCRtpSender.setOfferedRtpHeaderExtensions() and RTCRtpReceiver.setOfferedRtpHeaderExtensions().  This would remove the need for a direction attribute (which could be determined based on the header extensions configured for the sender and receiver).  But it would require applications to make two API calls instead of one. 

That should not be too complex to shim, if desired by web apps.

These two methods seem somehow easier to use and understand to me.
It is nice for instance to get the range of values directly from an object and set the value on the same object.
> From a model standpoint, I also don't want to have API on sender/receiver that would go away if we used something other than SDP to do negotiation.
> 
Can you clarify?
If we use something other than SDP, transceiver could potentially go away, but sender/receiver would still be there.

Looking at transceiver API, the only not-sender/receiver/direction-related method is setCodecPreferences.
Putting it at sender/receiver level would have brought some benefits if it had been feasible.
Like expressing asymmetric codec preferences: favour H264 encoding but favour H265 decoding, or enable VP8 decoder but disable VP8 encoder.

	Y