[webrtc-pc] A simulcast transceiver saved from rollback by addTrack doesn't re-associate, but unicast does (#2796)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== A simulcast transceiver saved from rollback by addTrack doesn't re-associate, but unicast does ==
A [JSEP rollback quirk](https://www.rfc-editor.org/rfc/rfc8829.html#section-5.7) makes it possible to save 🎣 a transceiver from the 🦈 jaws of rollback by associating it with `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](https://jsfiddle.net/jib1/0qf8uc3b/), 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? 🤷🏼‍♂️

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2796 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 31 October 2022 21:27:10 UTC