- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Nov 2022 19:00:20 +0000
- To: public-webrtc-logs@w3.org
The above tests used this order: sRD(simulcastOffer), addTrack, rollback. Naively, I expected the same result as addTrack, sRD(simulcastOffer), rollback, but [it differs](https://jsfiddle.net/jib1/0qf8uc3b/51) (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)](https://www.rfc-editor.org/rfc/rfc8829.html#section-4.1.10.2) which says rollback _"discards any proposed changes to the session, returning the state machine to the "stable" state"_. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2796#issuecomment-1298974993 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 November 2022 19:00:22 UTC