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)

[henbos]

Creating initial answers says to reject the m= section if "There is no offered media format that is both supported and, if applicable, allowed by codec preferences".

This makes sense to me, but IIUC the argument here is that since stopping the transceiver is inevitable, we might as well do it earlier (at setRemoteDescription(offer) as opposed to setLocalDescription(answer))?

Is there any benefit to doing it earlier? I'm biased towards not changing the spec if things are already working correctly. Also changing these kinds of things can have unintended consequences, for example the "rollback" steps reference trying to find a corresponding transceiver for the m= section and create one if it doesn't exist, so if we stop the transceiver earlier then we'd end up creating a second transceiver for the m= section as part of rollback only to stop it later? Not sure this reading is correct but this is the kind of thing I'm worried about.

[henbos]

Sorry I misunderstood, I thought you wanted to move the rejection from answer time to offer time.

The problem isn't that it gets rejected at SLD(answer) time, the problem is that while it got rejected and the transceiver "should" be stopped, it doesn't appear to be stopped?

That sounds like a clear bug if so