wyemond@ Thanks for the issue.

As this issue needs to be tested using transceiver, this setup is not available at TE-end to test and confirm the issue.
Hence adding 'TE-Hardware-Dependency' label and requesting the appropriate team to look into the issue and help in further triaging.

Thanks..

I should clarify that I am talking about RTCRtpTransceiver that was implemented in 69. 

Also the problem exists not only on Linux. 

Thank you, love the repro steps! :D

I see what's going on. Per-spec, "onunmute" should fire when RTP packets arrive. We currently don't do this, instead we create the track already unmuted. This is a known bug.

Per-spec, "onmute" happens when negotiation causes the receiver to no longer receive stuff for that receiver.

The next "ontrack" that reuses the receiver has no logic to make the track unmuted again!

We should fire these events based on RTP packets but that would be a harder change with more risk of flakes. I think an initial quick fix should be to unmute and queue to fire "onunmute" whenever "ontrack" causes a receiver's track to become active ('sendrecv' or 'recvonly').

hta@ FYI another blocker

(This was not a problem in "Plan B" because in that case you cannot reuse a receiver, it is simply removed.)

CL with a fix: https://chromium-review.googlesource.com/c/chromium/src/+/1249066

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92605c16c6f845a8ded3b018ac5adbc511446a5e

commit 92605c16c6f845a8ded3b018ac5adbc511446a5e
Author: Henrik Boström <hbos@chromium.org>
Date: Mon Oct 01 08:39:32 2018

[Unified Plan] Remote MediaStreamTracks should be muted by default.

Per-spec, tracks that are created with a receiver (e.g. addTrack or
setRemoteDescription) are muted by default. Prior to this CL they were
unmuted by default, whether or not they were receiving any packets.

A correct implementation should unmute the tracks when RTP packets
arrive. We are not quite there yet, this CL assumes that if the receiver
becomes active through renegotiation it will unmute. We are careful to
make sure that the track is muted on the "ontrack" event so that the
application has time to wire up the "onunmute" event.

By unmuting as part of processing SDP we fix the Unified Plan bug where
a remote track that had previously been muted was not unmuted when
becoming active again (transciever.currentDirection == 'sendrecv' or
'recvonly'),  https://crbug.com/884023 .

This CL also makes "ontrack" fire synchronously per-spec,
https://crbug.com/788558. Note that some stream events still fire
asynchronously, which means they now fire after the "ontrack" event in
the Unified Plan case. This is remaining work on that bug.

A new file is created to test muting related behaviors, and some helper
functions used this and another file are moved to
RTCPeerConnection-helper.js.

Bug:  884023 , 777619, 788558
Change-Id: I8dc3e2adf04e72282f085779639edc73bacfc86b
Reviewed-on: https://chromium-review.googlesource.com/1249066
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595405}
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCPeerConnection-helper.js
[add] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCPeerConnection-remote-track-mute.https.html
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCPeerConnection-transceivers.https-expected.txt
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCPeerConnection-transceivers.https.html
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/virtual/webrtc-wpt-unified-plan/external/wpt/webrtc/RTCPeerConnection-addTransceiver.https-expected.txt
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/WebKit/LayoutTests/virtual/webrtc-wpt-unified-plan/external/wpt/webrtc/RTCPeerConnection-transceivers.https-expected.txt
[modify] https://crrev.com/92605c16c6f845a8ded3b018ac5adbc511446a5e/third_party/blink/renderer/modules/peerconnection/rtc_peer_connection.cc

Verified that the jsfiddle is working as intended after the fix (Canary).