sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]]

[docfaraday]

Presently, the language that describes how to handle simulcast in a remote offer says that [[SendEncodings]] is completely replaced based on the rids in the simulcast attribute. While this works fine for transceivers that are not yet associated, for already associated transceivers (which have already populated [[SendEncodings]]), this is not appropriate.

We need to specify what happens on sRD(offer) when there is already an associated transceiver. Since we (rightly) allow sRD(answer) to remove pre-existing rids, we probably need to allow sRD(offer) to remove pre-existing rids as well (since the base simulcast spec requires the answerer to handle this situation). We also need to ensure that the language around createAnswer does the right thing if the offer tries to add a rid (ie; the answer will not contain that new rid).

It probably does not make sense to allow sRD(offer) to add or reorder rids on an already associated transceiver, but I suppose if there's a use-case we want to support we could try something like that. We also do not want to modify any preexisting element in [[SendEncodings]]; we should not try to automatically update scaleResolutionDownBy, for example. So sRD(offer) would only be able to remove elements from [[SendEncodings]], and no other modification would be possible, pretty much the same as the existing rules for sRD(answer).

[fippo]

isn't that related to chrome's continued lack of compliance in its so-called "spec-compliant simulcast"?

[docfaraday]

Possibly? I'm not sure exactly what you're referring to wrt bugs in Chrome simulcast.

[fippo]

see #2155

[docfaraday]

So the "lack of compliance" you're referring to is the lack of support for the change in #2155?

Whatever the case, #2155 is closely related to this issue.

[jan-ivar]

Yes we're failing to handle the "already associated" case correctly here, which was what I missed in #2155 (comment) (because the "else" of creating a new set of transceivers each time, is clearly not what anyone meant).

What @docfaraday proposed SGTM.

[aboba]

Feedback from June 19, 2022 WEBRTC WG Virtual Interim: "Ready for PR"