[webrtc-pc] sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]] (#2722)

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

== sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]] ==
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).

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


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

Received on Friday, 22 April 2022 17:40:06 UTC