(no subject)

On 1/14/20 4:21 PM, Henrik Boström wrote:
> 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.


RTP header extensions are, by definition, attached to RTP packets, not 
RTCP packets, so they go in the same direction as media - that is, 
senders only send them, and receivers only receive them.

Since WebRTC is symmetrical by design, I don't see how "applicable in 
one direction" is going to make sense.


>
> On Tue, Jan 14, 2020 at 10:44 AM Youenn Fablet <youenn@apple.com 
> <mailto:youenn@apple.com>> 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.
>
>     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
>