docfaraday

> It would be tempting to default scaleResolutionDownBy to 1 in the IDL, but that can't be done because the sendEncodings field is defined for both audio and video (although...

Another thing; it probably doesn't make much sense to throw RangeError when scaleResolutionDownBy is undefined in setParameters. If we want to throw something in this case, I think InvalidModificationError is...

RFC 8853 does not seem to prohibit duplicate rids in the simulcast attribute, although generating a simulcast attribute with duplicates would definitely be silly. I guess the appropriate thing to...

> @docfaraday mentioned offline a similar issue with addTrack and SRD(simulcastOffer). After more offline discussion, it seems like this particular question (what to do when setParameters races against sRD(simulcast offer))...

Also, we need to deal with setParameters racing against rollback.

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

So the "lack of compliance" you're referring to is the lack of support for the change in https://github.com/w3c/webrtc-pc/pull/2155? Whatever the case, https://github.com/w3c/webrtc-pc/pull/2155 is closely related to this issue.

Regarding 2 and 3, erroring out when a remote SDP tries to narrow the envelope would violate the base IETF spec, IMO. Base spec requires us to allow this. Whether...

So, disallowing a reoffer from expanding the envelope is fine, and does not require an error; you just form an answer that says "no" by not including the new rids....

> > Regarding 2 and 3, erroring out when a remote SDP tries to narrow the envelope would violate the base IETF spec, IMO. Base spec requires us to allow...