Re: [webrtc-pc] The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed (#2723)

Given that RFC8853 requires a reofferer to honor the removal of rids from the answer, and given that RFC8853 also requires the answerer to honor the removal of rids from a reoffer, I think it would be a mistake to have a blanket prohibition on the renegotiation of rids, whatever we end up doing. I think we need to at least support the removal of rids in renegotiation, if only to remain compliant with RFC8853.

Prohibiting the addition of rids seems acceptable to me; there's nothing in RFC8853 that requires an answerer to accept new rids in a reoffer, and of course it is already a RFC8853 violation for an answerer to add a rid that is not in an offer. That said, if there's a strong enough desire to allow the addition of rids in renegotiation, it would be acceptable also, but we'd need to think carefully about how that would fit with the automatic selection of scaleResolutionDownBy. My inclination is to avoid this mess unless there's some compelling use-case.

What we do with rid reordering is a little more subtle. RFC8853 states that the rid order establishes a transmission preference, but does not say anything about what ordering implies about fidelity; in fact, there are examples where the first rid is the highest fidelity encoding. webrtc-pc is what specifies that the fidelity goes from low to high (and even then, this only applies when creating a set of encodings from an answer). RFC8853 does not explicitly forbid reordering rids in an answer as far as I can tell, although this seems like an oversight to me; if an offerer requests simulcast with a transmission preference, I think it is a bad idea for the answerer to switch up that ordering. RFC8853 definitely does not prohibit a reoffer from reordering rids, so throwing an error if we receive such a reoffer seems like a violation of RFC8853 to me. I think that if we are to be complaint with RFC8853, we have to allow rid reordering, if only to allow modification of the transmission preference. I do not think it is a great idea to try to modify the fidelity through reordering, though.

-- 
GitHub Notification of comment by docfaraday
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2723#issuecomment-1106913109 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 21:51:35 UTC