Re: [webrtc-extensions] Potential web compat issue with setOfferedRtpHeaderExtensions (#130)

> setParameters is the wrong mindset. setCodecPreferences is more similar.

Sure, let's use that. My point the same: set requires output from get as input, i.e. no hardcoded inputs, modulo For [example](
const {codecs} = RTCRtpSender.getCapabilities("video");
codecs.sort((a, b) => b.mimeType.includes("H264") - a.mimeType.includes("H264"));
Both setCodecPreferences and setParameters establish this get-before-set pattern, and setOfferedRtpHeaderExtensions violates it, because from what I can tell, this works:
tc.setOfferedRtpHeaderExtensions([{uri: "urn:ietf:params:rtp-hdrext:ssrc-audio-level", direction: "stopped"}]);
This is what I think is bad and creates a web compat headache, because it's simpler to write code that breaks web compat that code that doesn't.

If you agree this wasn't the intent, which it sounds like you do if you're saying setCodecPreferences is the right model, then we can work to fix this. 

I've already identified a couple of problems that need fixing to make this work more like setCodecPreferences:
 1. structuredClone shouldn't be needed
 2. partial arrays are a sign input isn't from get, and shouldn't be allowed
 3. The algorithm doesn't weed out duplicates like setCodecPreferences does

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 6 December 2022 00:40:38 UTC