WebRTC: how to detect when a stream or track gets removed from a PeerConnection, in Firefox?

Question

onremovestream has been deprecated (and removed from Firefox), while onremovetrack is not yet implemented in Firefox.

How do I detect when a stream or track is being removed in Firefox?

Prescript

If the user leaves the room then the peerconnection closes and this will trigger oniceconnectionstatechange and also onsignalingstatechange events, both iceConnectionState and signalingState will be 'closed'. – Coition

This is correct. However, I am getting a consistent delay between the user leaving the room and oniceconnectionstatechange actually being fired (sometimes). – Prescript

@DanieleMolinari Please update your question with more specifics about the problem you're trying to solve. From your comment it sounds like you're trying to detect a remote peer dropping, which has nothing to do with negotiating away a track (which was what onremovestream was for). – Damp

@Damp My question originally included an "how to detect when the user leaves the room" part. Since @Coition is right on the oniceconnectionstatechange, I removed it from the question. What I am trying to solve is the case when a user adds multiple video streams, then removes one. – Prescript

Answer 1

You use onremovetrack on the receiving stream:

pc.ontrack = ({track, streams: [stream]}) => {
  track.onunmute = () => {
    if (!video.srcObject) video.srcObject = stream;
  };
  stream.onremovetrack = ({track}) => {
    console.log(`${track.kind} track was removed.`);
    if (!stream.getTracks().length) {
      console.log(`stream ${stream.id} emptied (effectively removed).`);
    }
  };
};

The above ontrack will run when e.g. the other side adds a track (and negotiates):

const sender = pc.addTrack(track, stream);

Now, whenever that other side calls either pc.removeTrack(sender) or sets transceiver.direction = "recvonly" (and negotiates), you should see the removetrack event fire.

Here's an example that should work in all browsers.

Things to keep in mind

In standard WebRTC ("unified-plan") our transceiver.receiver.track isn't ended when this happens, because it is wired to the other side's transceiver.sender, not the other side's transceiver.sender.track.

Instead of ending, our receiving track is muted and removed from its stream(s).

This is because pc.removeTrack(sender) only sets the sender.track to null and transceiver.direction to recvonly (requiring negotiation).

A sender may thus resume sending data using sender.replaceTrack(newTrack) and setting transceiver.direction = "sendrecv" again. On this happening, our receiver.track would be unmuted again and reinserted into the stream(s), firing the addtrack events on the stream(s). This also fires the track event again. Explore all the events in this blog's interactive section.

A receiving track is only truly ended by transceiver.stop() (locally or through negotiation), or pc.close().

Damp