[webrtc-pc] On track removal: Should you mute an already muted track? (#2506)

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== On track removal: Should you mute an already muted track? ==
If a track is negotiated to receive we fire ontrack regardless of packets flowing.

I can't find the relevant spec reference for this, but we should only fire onunmute when we've received RTP packets (and have a decoded frame to render?).

The removeTrack() section says...

> When the other peer stops sending a track in this manner, the track is removed from any remote MediaStreams that were initially revealed in the track event, and if the MediaStreamTrack is not already muted, a mute event is fired at the track.

It says "is not already muted", but our SDP processing does this:

> For each track in muteTracks, [set the muted state](https://rawgit.com/w3c/mediacapture-main/master/getusermedia.html#set-track-muted) of track to the value true.

Which references an algorithm that does not care if the track is already muted, it fires onmute regardless.

So what is the intent? If the track is still muted because we haven't received RTP packets yet, does onmute fire or not?
- If yes, onmute acts like the legacy "onremovetrack" which is nice, but it would be confusing if this was used both for RTP and for negotiation, rather than as a way to tell if we have media flowing, and muting an already muted track looks like a bug.
- If no, there are edge cases were onmute doesn't fire which could catch an application by surprise.

Is the intent that an application should manually loop through all transceivers and check its currentDirection before and after the negotiation to detect if a track was removed in a way that does not race with RTP packets?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2506 using your GitHub account

Received on Friday, 3 April 2020 11:58:05 UTC