Webrtc-pc: setCodecPreferences and transceiver direction change

[Orphis]

In #1998 , it was made clear that the codec preferences is dependent on the transceiver direction.
What should happen when there are codec preferences and a change of direction on a transceiver?

If the transceiver was marked sendonly and had a codec preference to use a codec that can only be sent, not received and is later changed to recvonly, it is clear the preference won't work anymore.

[ibc]

Even keeping SDP as it is, life would be much easier if we split RtcTransceiver into RtcSendTransceiver and RtcRecvTransceiver separate classes.

Yes, that means that a transceiver (and hence a m= section) can just send or receive, but not both. This way we avoid issues like the above one and get rid of the direction attribute difficulties.

And it's 100% standard as per SDP and Unified-Plan specs.

[ibc]

To summarize:

Please, remove the constraint and limitation on what we send just because we want also to receive, and viceversa.

[alvestrand]

The transceiver is introduced solely to represent the (in my opinion design mistake) binding of a sender and receiver that SDP demands.
we may want to make setCodecPreferences a sender/receiver function, and have the transceiver lift the preferences up from the sender/receiver as appropriate when generating SDP.

[alvestrand]

we already have setCodecPreferences on the sender (which directs what you send and doesn't cause negotiatinNeeded); we could claim that setCodecPreferences on the transceiver affects only the receiver (and the only thing it can do with it is to reflect it back when the transceiver asks for it)

[ibc]

Is there anyone already using one or two transceivers for sending and receiving and many other transceivers for just receiving (SFU scenario)? Or is people avoiding this as hell?

[aboba]

@alvestrand We don't have setCodecPreferences() on the sender, only setParameters().

If we add setCodecPreferences() to both sender and receiver, what happens when direction = “sendrecv” and sender/receiver codec preferences are set differently?

We can ignore codecs not supported for both sending and receiving, but what to do about ordering? Let sender order take precedence? This doesn't seem that different from potential options for clarifying transceiver.setCodecPreferences, where for direction = "sendrecv" we could also ignore codecs not supported for both sending and receiving.

[henbos]

At TPAC, we decided that setCodecPreferences should remain on the transceiver, per @aboba's slide:

Alternative 1: Leave setCodecPreferences() as a transceiver method, but better define its operation:

• When direction = “sendrecv” codecs included in createOffer/createAnswer are filtered by the intersection of Receiver and Sender.getCapabilities().codecs[]
• When direction = “sendonly” codecs included in createOffer/createAnswer are filtered by sender.getCapabilities().codecs[]
• When direction = “recvonly” codecs included in createOffer/createAnswer are filtered by receiver.getCapabilities().codecs[]

I'll make a PR that makes the operations well defined, including internal slots and steps to run.

[henbos]

Filed issue to test: https://github.com/web-platform-tests/wpt/issues/14396