- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 31 Oct 2022 21:27:09 +0000
- To: public-webrtc@w3.org
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