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

commit 1efc13c049cd97418f9c3175ad072bf921f38ccc
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Fri Jan 18 07:13:03 2019

Sheriff: Mark external/wpt/webrtc/RTCDTMFSender-ontonechange.https.html as flaky on Mac

Bug:  923244 
Change-Id: Ibf8226768c75cde57106ffa3c4ea36cf549b3826
Tbr: nhiroki@chromium.org
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/1420513
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624026}
[modify] https://crrev.com/1efc13c049cd97418f9c3175ad072bf921f38ccc/third_party/blink/web_tests/TestExpectations

Sample result:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/WebKit%20Mac10.13%20%28retina%29/9179

--- /b/s/w/ioE0_mlH/layout-test-results/external/wpt/webrtc/RTCDTMFSender-ontonechange.https-expected.txt
+++ /b/s/w/ioE0_mlH/layout-test-results/external/wpt/webrtc/RTCDTMFSender-ontonechange.https-actual.txt
@@ -6,7 +6,7 @@
 PASS insertDTMF() with duration less than 40 should be clamped to 40
 PASS insertDTMF() with interToneGap less than 30 should be clamped to 30
 PASS insertDTMF with comma should delay next tonechange event for a constant 2000ms
-FAIL insertDTMF() with transceiver stopped in the middle should stop future tonechange events from firing assert_greater_than: More tonechange event is fired than expected expected a number greater than 0 but got 0
+PASS insertDTMF() with transceiver stopped in the middle should stop future tonechange events from firing
 PASS Calling insertDTMF() in the middle of tonechange events should cause future tonechanges to be updated to new tones
 PASS Calling insertDTMF() multiple times in the middle of tonechange events should cause future tonechanges to be updated the last provided tones
 PASS Calling insertDTMF('') in the middle of tonechange events should stop future tonechange events from firing

Findit identified the culprit r623872 as introducing flaky test(s)
summarized in https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vMDcwMjFlYzg1NjA4MzZkMmY3NWE4MGFlOTAzZTdkN2UzMzNkZTk4Ygw

Please revert the culprit or disable the test(s) asap. If you are the owner,
please fix!

If the culprit above is wrong, please file a bug using this link:
https://bugs.chromium.org/p/chromium/issues/entry?status=Unconfirmed&labels=Pri-1,Test-Findit-Wrong&components=Tools%3ETest%3EFindit%3EFlakiness&summary=%5BFindit%5D%20Flake%20Analyzer%20-%20Wrong%20culprit%20r623872&comment=Link%20to%20Culprit%3A%20https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vMDcwMjFlYzg1NjA4MzZkMmY3NWE4MGFlOTAzZTdkN2UzMzNkZTk4Ygw

Automatically posted by the findit-for-me app (https://goo.gl/Ot9f7N).

Will do! :)

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

commit 37fb313b36682f925bd3189b3faf04e78d0dc46e
Author: Henrik Boström <hbos@chromium.org>
Date: Fri Jan 18 09:34:39 2019

Mark RTCDTMFSender-ontonechange flaky on all platforms.

TBR=hta@chromium.org
NOTRY=True

Bug:  923244 
Change-Id: I6d06dc1bd21e4254e1882a13e04520593b8893f9
Reviewed-on: https://chromium-review.googlesource.com/c/1420797
Reviewed-by: Henrik Boström <hbos@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624050}
[modify] https://crrev.com/37fb313b36682f925bd3189b3faf04e78d0dc46e/third_party/blink/web_tests/TestExpectations

The test is flaking because RTCRtpTransceiver.stop() is not implemented so the tones don't stop sending and the test determines whether or not it is finished listening based on a timeout, which means it could sometimes get lucky and pass.

I'll merge this into a bug for implementing stop().