W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2020

(no subject)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 14 Jan 2020 16:50:49 +0100
To: public-webrtc@w3.org
Message-ID: <27ec70f2-441b-113d-54c7-3509a6546e19@alvestrand.no>

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
Received on Tuesday, 14 January 2020 15:51:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:51 UTC