- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Mar 2018 17:11:00 +0000
- To: public-webrtc-logs@w3.org
> `transceiver.stop()` fires the ended event on remote tracks on both ends... But it doesn't remove the track from its stream I guess my assumption, which may be incorrect, was that a rejected (port 0) m= section would be interpreted as having an `inactive` direction, and thus would cause tracks to be removed. > I think you mean this case (assuming live tracks in both directions): > ```js > await pc1.setLocalDescription(await pc1.createOffer()); > await pc2.setRemoteDescription(pc1.localDescription); > pc2.getTransceivers()[0].direction = "inactive"; > await pc2.setLocalDescription(await pc2.createAnswer()); > await pc1.setRemoteDescription(pc2.localDescription); > ``` > When I run [this](https://jsfiddle.net/jib1/s4o9ykdL/) in Firefox 59 I get: > ``` > pc1's received track removed > pc1's received track muted > ``` > ...but not on pc2. Right. Though if pc2 generates a new `inactive` offer, its remote track would be removed upon applying the answer. The main difference in my example is that after recycling, it's too late for it to be removed. > Perhaps firing events in SRD(offer) is too soon? Meaning, we should delay all track events until setting an answer? That would work, I'd just worry about breaking existing applications. It may be safer to process the removal in SLD(answer) (so, "step 4" in the original issue description). That would handle both my scenario and yours. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1778#issuecomment-371555125 using your GitHub account
Received on Thursday, 8 March 2018 17:11:05 UTC