Applying a remote offer with unsupported codecs results in stale transceiver

[mickel8]

Consider scenario where we apply an initial remote offer, which doesn't contain any supported (by us i.e. receiver) codecs.

According to W3C we will create a new transceiver with recvonly direction, then we will create an answer that will mark the mline as rejected (as there are no supported codecs) and finally, we will apply the answer as our local description.

Applying a local answer is defined in section 4.4.1.5-4.7.10.1 and it doesn't allow for stopping transceivers. Stopping transceivers is only done when applying a remote description. Beacuse, when applying the remote offer, we didn't create a stopped transceiver, we won't also stop it when applying the local answer. This means that we will end up with an answer with the rejected mline and the transceiver with direction recvonly and currentDirection recvonly or inactive (depending on what we put in the answer as JSEP defines rejecting an mline as setting port to 0, without changing the direction, see here).

What I think should happen is that we should also stop transceivers when applying local description, so I belive we should add in 4.4.1.5-4.7.10.1 something like in the 4.4.1.5-4.7.10.2

"If the media description is rejected, and transceiver.[[Stopped]] is false, then stop the RTCRtpTransceiver transceiver."

That's also what Firefox seems to do.

We offer AV1 as Firefox 121 doesn't support it and at the end of the day the transceiver created after setting a remote description is removed when we apply local description.

See https://jsfiddle.net/mickel8/2zjqnutc/

[fippo]

That seems to be the reasonable consequence if you offer a set of codecs not supported? It should be stopped though...

I'm somewhat concerned Edge M120 throws an error on the fiddle but that seems to be resolved in Edge Canary either by virtue of "go AV1" or because of this commit

[mickel8]

That seems to be the reasonable consequence if you offer a set of codecs not supported?

What exactly?

I'm somewhat concerned Edge M120 throws an error on the fiddle but that seems to be resolved in Edge Canary either by virtue of "go AV1" or because of this commit

Thanks! We have very similar test in our Elixir implementation except that we also ensure that transceivers are removed (link)