- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Mar 2023 11:03:13 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-pc: == RTCRtpEncodingParameters.active flag and the ~ in the SDP == If an encoding is inactive and you negotiate SDP we put a ~ in front of the RID to signify that it is inactive. Now first of all, that seems rather useless, because the active flag can change at any moment without triggering re-negotiation, so I'm not sure what the other endpoint is supposed to do with that information when there is no guarantee that the ~ is up to date. So far, the ~ just seems pointless and misleading, but not causing any serious harm. But it gets worse. It turns out that Chromium will look the existence or non-existence of the ~ in remote SDP and _update the encodings[i].active flag based on this information_. This is madness! Case and point: 1. active=true; createOffer and send it to the other endpoint. 2. active=false due to user clicking mute button. 3. Other endpoint gets the SDP offer, sees active encodings and naturally creates an answer containing no ~. 4. We get the answer back, do SRD(answer) and boom. Now active=true, unmuting the stream. I expect real world apps to also do replaceTrack(null) when muting to avoid this becoming a privacy issue, but I find the remote endpoint being able to control the active flag completely unacceptable. Qs: 1. Is Chromium's use of this flag a bug or a feature? 2. Regardless if this is intentional or not, can we either remove ~ or clarify in the spec that one must NOT update the local active status based on SDP? Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2848 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 28 March 2023 11:03:15 UTC