Re: Transceiver API vs sender/receiver API

On 1/14/20 10:43 AM, Youenn Fablet wrote:
>
>
>> On 14 Jan 2020, at 09:02, Harald Alvestrand <harald@alvestrand.no 
>> <mailto: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.

If we don't use SDP (and in particular, if we don't use offer/answer), 
the whole concept of offers and answers goes away. I don't want to 
artificially preserve it.

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

We do have the enable / disable codec features on sender (where they 
belong). What we don't have is an API on sender to tell it what codecs 
and configurations the sender is allowed to set. At the moment, that's 
(conceptually) a hidden interface between Sender and Transceiver.

The inability to negotiate asymmetric codec sets is a property of SDP, 
and accurately reflected in the Transceiver API.