- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Aug 2022 20:59:08 +0000
- To: public-webrtc-logs@w3.org
> 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 this breaks webrtc-pc is another question, but my position is that webrtc-pc should not be contradicting the IETF spec that it is based on. I don't think it breaks anything and browsers are already following the IETF spec here, so this spec should probably yield. > Regarding 6, this seems wrong. If offer/answer removes a rid by narrowing the envelope (which I think needs to be allowed, see previous line), it should probably not show up in JS anymore. To clarify: 6 is about this line: _"If the number of [RTCRtpEncodingParameters](https://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters) now stored in sendEncodings is 1, then remove any [rid](https://w3c.github.io/webrtc-pc/#dom-rtcrtpcodingparameters-rid) member from the lone entry."_ Browsers _do_ trim the encodings array, they just don't get rid (no pun intended) of the rid member holding the name of the last remaining encoding when the array length is down to 1. It looks like the a=simulcast line does go away a few renegotiations after this, so removing the rid member like the spec says seems consistent with the SDP browsers produce, so perhaps implementations should fix this. > Regarding 7, that's just bonkers. An answer that contains rids that the offer did not is invalid per base spec, and should result in an error. Makes sense to me. I doubt this would break anyone. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2762#issuecomment-1205761445 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 August 2022 20:59:09 UTC