webrtc-pc
webrtc-pc copied to clipboard
w3c
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", then run the following steps:
- For each transceiver in the connection's set of transceivers run the following steps:
- If transceiver is stopped, associated with an m= section and the associated m= section is rejected in connection.[[CurrentLocalDescription]] or connection.[[CurrentRemoteDescription]], remove the transceiver from the connection's set of transceivers.
Removing transceivers like this is covered by this WPT. The same file also tests that transceivers stopped prior to being negotiated never show up in the SDP which is also good.
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: "negotiation is the only place where transceivers are removed today, so let's be consistent with that."
Thoughts, my fellow transciever enthusiast @jan-ivar? I'm leaning towards Proposal A but I don't have a strong opinion
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.
(Actually not sure what the correct behavior is here... but Canary behaves this way as of recently)
Moving DC discussion to #2839. Let this issue only talk about transcievers in limbo :)
The same file also tests that transceivers stopped prior to being negotiated never show up in the SDP which is also good.
- Proposal C: Implement the spec. There is no [edit: W3C] spec support for that green WPT test.
The spec is quite clear: stop(): "Irreversibly marks the transceiver as stopping ... cause[ing] future calls to createOffer to generate a zero port in the media description for the corresponding transceiver, as defined in [RFC8829] (section 4.2.1.) (The user agent MUST treat a stopping transceiver as stopped for the purposes of RFC8829 only in this case)."
The WPT may predate our stopping hack.
Section 5.2.1 says "The next step is to generate "m=" sections, as specified in [RFC4566], Section 5.14. An "m=" section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped RtpTransceivers".
This seems to have supported the green WPT before the stopping hack, so it would perhaps be nice to preserve that JSEP logic, and I see no need to break it.
If we added another "MUST treat a stopping transceiver as stopped" JSEP hack here as well, then that might support the green WPT.
But with Proposal A we wouldn't even need that hack, I think, which seems promising.
@docfaraday WDYT?
Yep, I think the test was prior to our changes and I don't think our changes intended to change this specifically, only address the offerer tagged footgun.
Considering all browsers already align on the old JSEP behavior I think we should just clarfiy/decide when to remove them from the set of transceivers
So add to the "stopping" steps something like "if transceiver is not associated with a media section, move to stopped state and remove from the list of transceivers"?
