- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 11:41:21 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-pc: == Transceivers stopped prior to being negotiated are never removed from the set of transcievers == The spec has this to say about removing stopped transcievers and it happens in response to negotiating: > - If description is of type "[answer](https://w3c.github.io/webrtc-pc/#dom-rtcsdptype-answer)", then run the following steps: > > - - For each transceiver in the connection's [set of transceivers](https://w3c.github.io/webrtc-pc/#transceivers-set) run the following steps: > > - - - If transceiver is [stopped](https://w3c.github.io/webrtc-pc/#dfn-stopped), [associated](https://w3c.github.io/webrtc-pc/#dfn-associated) with an m= section and the associated m= section is rejected in connection.[[[CurrentLocalDescription]]](https://w3c.github.io/webrtc-pc/#dfn-currentlocaldescription) or connection.[[[CurrentRemoteDescription]]](https://w3c.github.io/webrtc-pc/#dfn-currentremotedescription), remove the transceiver from the connection's [set of transceivers](https://w3c.github.io/webrtc-pc/#transceivers-set). Removing transceivers like this is [covered by this WPT](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/RTCRtpTransceiver-stop.html;l=136;drc=232359e58644a36b534576ec7b65d070c4f75040). The same file also tests that [transceivers stopped prior to being negotiated never show up in the SDP](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/RTCRtpTransceiver-stop.html;l=22;drc=232359e58644a36b534576ec7b65d070c4f75040) which is also good. (Side-note: this is also consistent with DCs: if the only DC that exists is closed prior to being negotiated, we don't add an m=application line to the SDP. Makes sense!) But this also makes it possible for a transceiver to end up in "limbo" if stopped prior to being negotiated: - It will never get an m= section because it is stopped, but it will never be removed from the set of transceivers because it is never formally a rejected m= section. How do we resolve this issue? - **Proposal A**: Immediately remove the transceiver from the set of transceivers. Argument: "why need to negotiate something that is not even in the SDP?" - **Proposal B**: Delay the remove until the next SDP answer is set. Argument: "this is the only place where transceivers are removed today, so let's be consistent with that." Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2838 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 March 2023 11:41:23 UTC