Specify what should happen if filtering [[PreferredCodecs]] on direction results in empty list

[henbos]

If you have no preference, you O/A with all codecs.

But if you have a recvonly codec preferences, and the transceiver is sendonly, the createOffer() filtering would result in an empty list.

• What happens?

[fippo]

The list of codecs is empty so the m-line is rejected in the offer (port 0) and calling setLocalDescription with it causes the transceiver to be stopped.

[henbos]

I would rather act as if you have no preference than to have the transceiver blow up. Also if we stop transceivers before offer in other contexts I'm not sure we offer it, or if we do what about offerer tagged m= section and the stopping vs stopped state.

Probably less error prone to simply act as if you have no preference

[fippo]

No preference would be against the users intent to set codec preferences. Rejecting and stopping the transceiver when there is nothing in common is more consistent with the same results when you get a remote answer with no codecs in comon

[henbos]

Why would me saying which codecs I prefer to receive make a sendonly transceiver not just incapable of sending, but make the transceiver permanently die?

If this was "just receiver preferences", then setCodecPreferences would be a NO-OP. But it's not:

transciever.direction = 'sendrecv';
transceiver.setCodecPreferences([recvOnlyCodec]);
O/A and everything works, other endpoint is asking for H264

transceiver.direction = 'sendonly';
O/A and transceiver is permanently stopped, other endpoint is not allowed to ask for H264 anymore

To safely change direction, the app needs to remember to clear their preferences or to always add dummy codecs just for the sake of having SOMETHING in the offer. Even if that something is not what the other endpoint is interested in.

It's a footgun. Possible workaround:

• Setting direction or codec preference in a way that results in an empty preference could throw.
• Sensible defaults could be used.
• Setting direction to sendonly automatically clears any preferences.

But I think whether we fail hard or patch this issue with workarounds, I think it's clear that receiver preferences ARE relevant for senders. JSEP does not allow not offering anything, and what we offer - even in a sendonly use case - are the "receiving" codec preferences. Receiving in scare-quotes.

[henbos]

@alvestrand @aboba

[henbos]

Another workaround could be: if you end up with the empty set, make sure we always have something to offer by adding a sendrecv codec of the UA's choice.

[henbos]

Filed #2937 for a more concrete example