(no subject)

Are there any extensions that are only applicable in one direction? If so,
having the capabilities on a per-sender and per-receiver basis would avoid
having to filter out the lists.

On Tue, Jan 14, 2020 at 10:44 AM Youenn Fablet <youenn@apple.com> wrote:

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