The language around setting a description appears to prohibit renegotiation of RIDs

[docfaraday]

"If the description attempted to renegotiate RIDs, as described above, then reject p with a newly created InvalidAccessError and abort these steps."

While it is fine to prohibit a local reoffer from adding or removing RIDs, or changing the simulcast envelope, it is a violation of RFC8853 for an offerer to refuse to honor a remote answer that rejects a previously negotiated RID, and it is also a violation of RFC8853 for an answerer to refuse to honor a remote offer because it removed a previously negotiated RID.

[jan-ivar]

The "described above" language says: "This specification does not allow remotely initiated RID renegotiation.". Remotely initiated = remote offer.

We explicitly prohibited remote offers from renegotiating RIDs in #2314. Do we have new information to revisit that decision?

it is a violation of RFC8853 for an offerer to refuse to honor a remote answer that rejects a previously negotiated RID

Side-note: if you remove "previously negotiated" from that sentence then I agree, and I've filed #2743 on that.

But reading RFC8853 I find very little mention of previously negotiated state. To me it doesn't appear to make any distinction between initial O/A and renegotiation. I therefore find it hard to infer the requirements of these simulcast attributes on subsequent O/A.

I know JSEP has such language, but it's not clear to me how that maps here.

For instance: RFC8853's example mentions an offer to send 3 layers, with an answer to receive 2. Is a subsequent identical O/A acceptable because the net result is the same? If so, what if the answer doesn't reject the 3rd layer the second time? Now we've added a layer, is that acceptable?

it is also a violation of RFC8853 for an answerer to refuse to honor a remote offer because it removed a previously negotiated RID.

Same here, if you could quote where it says that it would help.

[jan-ivar]

So with #2758 merged, the current language here is: "if none of the encodings in transceiver.[[Sender]].[[SendEncodings]] contain a rid member whose value matches any of the rids in the simulcast attribute, then fail the process of applying description."

A decent reduction in cases where sRD can fail, but one remains.

According to @docfaraday offline, there are very few situations where an sRD(offer) should error out due to an inconsistency with something previously negotiated (things like removal of m-sections).

He suggested sRD not fail here, and that the answer simply won't be simulcast. This seemed so simple, I said I'd do a PR and a slide for the November interim.