[webrtc-pc] setCodecPreferences, sendonly codecs and dummy codecs (#2937)

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== setCodecPreferences, sendonly codecs and dummy codecs ==
As of recent changes, we force you to have at least one codec capable of receiving, regardless of direction, or else `setCodecPreferences` throws.
But we also allow codecs of any direction to be in the SDP as well as filter what we do end up preferring based on direction.

This means that we still allow the JSEP use case of setting default preferences on the sender side in case the receiver has no preferences on their own, in this case the answer should be the same preference list as was in the offer.

This illustrates controlling sender codec from the offerer assuming answerer justs acks it:
```
// Does not reject because RecvCodec is a receiver codec.
setCodecPreferences([SendOnlyCodec, RecvOnlyCodec]);

// Ensures a sendonly filter is applied at createOffer
transceiver.direction = 'sendonly';

// Filter to [SendOnlyCodec], this is fine to offer since we're not
// receiving so we don't need to include RecvOnlyCodec
createOffer()
```

So it works! But it also shows something silly: we had to include `RecvOnlyCodec` in order to offer `SendOnlyCodec`. But it's not actually preferred in the SDP, this is just a "dummy codec". So why do we force the app to add it?

Dummy codecs might be fine to protect against footguns when the direction changes in the future, but in that case we should also throw if `setCodecPreferences([RecvOnlyCodec])` is called since it breaks the `sendonly` offer use case.

We should either let the app specify codecs regardless of direction, or we should be consistent with our foot gun protection and enforce that the app always has something to offer in both directions, including sending.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2937 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 13 February 2024 09:04:03 UTC