A simulcast transceiver saved from rollback by addTrack doesn't re-associate, but unicast does

[jan-ivar]

A JSEP rollback quirk makes it possible to save 🎣 a transceiver from the 🦈 jaws of rollback by associating it w/ addTrack:
"... an RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method. This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have an "m=" section for the added track appear in the generated offer."

When I test this, I find some interesting results (Chrome and Safari):

PASS transceiver saved from rollback of sRD(simulcastOffer) by addTrack is simulcast
FAIL transceiver saved from rollback of sRD(simulcastOffer) by addTrack can be re-associated: Expected exactly one transceiver - Expected 1, got 2 failed
PASS transceiver saved from rollback of sRD(unicastOffer) by addTrack can be re-associated

Basically, if you were looking for a way to add simulcast encodings with addTrack, then yay (who needs addTransceiver?) 🙃

But I also found that a simulcast transceiver saved from rollback by addTrack doesn't re-associate, whereas a unicast transceiver does.

This doesn't seem POLA. Not sure what I expected, but it seems odd that they behave differently perhaps. What should it do? 🤷🏼‍♂️

[jan-ivar]

The above tests used this order: sRD(simulcastOffer), addTrack, rollback.

Naively, I expected the same result as addTrack, sRD(simulcastOffer), rollback, but it differs (in Chrome):

PASS transceiver saved from rollback of sRD(simulcastOffer) by upfront addTrack is unicast
FAIL transceiver saved from rollback of sRD(simulcastOffer) by upfront addTrack can be re-associated: Expected exactly one transceiver - Expected 1, got 2 failed
PASS transceiver saved from rollback of sRD(unicastOffer) by upfront addTrack can be re-associated

(and Safari):

FAIL transceiver saved from rollback of sRD(simulcastOffer) by upfront addTrack is unicast: Expected exactly one transceiver - Expected 1, got 2 failed
FAIL transceiver saved from rollback of sRD(simulcastOffer) by upfront addTrack can be re-associated: Expected exactly one transceiver - Expected 1, got 2 failed
PASS transceiver saved from rollback of sRD(unicastOffer) by upfront addTrack can be re-associated

The main takeaway (from Chrome) is simulcast is rolled back to unicast for transceivers created by addTrack, but not for transceivers created by sRD.

I think the solution is to roll back simulcast to unicast for transceivers created by sRD as well, if they're going to stick around.

This seems a defensible interpretation of RFC 8829 (section 4.1.10.2) which says rollback "discards any proposed changes to the session, returning the state machine to the "stable" state".

[docfaraday]

I concur that the reasonable thing to do in this situation is to roll back to ridless unicast.

[jan-ivar]

Ready for PR based on last meeting.

[jan-ivar]

Solved by #2797.