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

> setParameters is different because it is more dynamic and harder to come up with valid input.

I'd argue it's equally hard to come up with valid input to setCodecPreferences:
- _"The codecs sequence passed into [setCodecPreferences]( can only contain codecs that are returned by [RTCRtpSender]([getCapabilities]( or [RTCRtpReceiver]([getCapabilities](, where kind is the kind of the [RTCRtpTransceiver]( on which the method is called. Additionally, the [RTCRtpCodecCapability]( dictionary members cannot be modified. If codecs does not fulfill these requirements, the user agent MUST [throw]( an [InvalidModificationError]("_

See for details.

> > partial arrays are a sign input isn't from get, and should be disallowed
> This model does not work for codec preferences,

Thanks for pointing out setCodecPreferences accepts partial arrays, but the semantics are different from here. In setCodecPreferences, _"the [user agent]( MUST use the indicated codecs, in the order specified in the codecs argument"_, which I interpret to mean MUST ONLY use the indicated codecs. IOW, leaving a codec out means: don't use it.

Compare to [setOfferedRtpHeaderExtensions](, where leaving out a header extension means: don't modify it and leave it as-is. This is the cherry-set pattern we abandoned years ago for setParameters, and is the pattern I fear invites hard-coding.

This also seems confusing, especially since the names _seem_ to invoke the same semantics: set what must be used (and use no more).

Would you be OK with treating each extension NOT in extlist as having the value `direction: "stopped"`?

I think that would solve both this semantic inconsistency and my concern over hard-coded strings sufficiently.

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 16:54:22 UTC