there are 2 web-platform-tests which are expected TIMEOUT on all platforms:
/webrtc/RTCRtpReceiver-getSynchronizationSources.https.html
/webrtc/RTCDataChannel-close.html

I have confirmed these fail for me locally and it is hard to get more information as the command window where I ran the tests from spewed so much server? output.

for /webrtc/RTCDataChannel-close.html, I see this in the devtools console:
WebRTC: ICE failed, add a STUN server and see about:webrtc for more details

for /webrtc/RTCRtpReceiver-getSynchronizationSources.https.html, I see this in the UI describing the test where we timeout:
[video] getSynchronizationSources() eventually returns a non-empty list

:dminor, is this something you can look into and determine if this is fixable, not supported, an issue with tests/tools. or something to redirect to someone else?

Byron has been keeping an eye on our web-platform tests.

Looks like the sync sources test was failing due to bug 1525394, but that is fixed and they still fail. Looking into why.

Not sure about webrtc/RTCDataChannel-close.html

Determined reason for timeouts in RTCDataChannel-close.html, and it seems that the fix for RTCRtpReceiver-getSynchronizationSources.https.html was incomplete, so I have re-opened that bug.

Actually, since we already have bugs filed for these problems, let's close this one once we get the bug links in the ini file.

Ok, in the meantime some change has landed that causes these tests to fail before they time out. Looking into it.

Two of the failures in RTCDataChannel-close.html are due to bug 1611953, but the third is due to this code expecting an error event when the other PC is closed:

https://searchfox.org/mozilla-central/rev/df4c90d4b8c92c99f76334acfe4813c573c12661/testing/web-platform/tests/webrtc/RTCDataChannel-close.html#49-70

I don't see any support for this in the spec, do you? Seems like closing the other PC ought to result in graceful shutdown of the datachannel.

Note I'm working on RTCDataChannel-close.html atm. I'll try to rework them to test without timeout.

(In reply to Byron Campen [:bwc] from comment #7)

I don't see any support for this in the spec, do you? Seems like closing the other PC ought to result in graceful shutdown of the datachannel.

pc.close() says: "The RTCDataChannels will be closed abruptly and the closing procedure will not be invoked.".

I.e. data may be lost. Section 6.2 of draft-ietf-rtcweb-data-channel says: "In case of a non-graceful teardown, all data channels are also closed, but an error indication SHOULD be provided if possible."

So the test seems accurate. In Chrome https://jsfiddle.net/jib1/kep8tgz1/18/ produces:

OperationError: Transport channel closed

ponders the normative meaning of SHOULD IF POSSIBLE

So, pc.close() should un-gracefully tear down SCTP, but gracefully tear down RTP (by sending BYE)? Awesome. Seems like a spec bug to me.

Also, Chrome fires that "OperationError: Transport channel closed" waaaaaaay too fast for it to be due to non-graceful shutdown. That SCTP stream is being closed in the normal way, from an SCTP perspective, which is not an error as such.

Also, "The RTCDataChannels will be closed abruptly and the closing procedure will not be invoked" is pretty ambiguous here. The "closing procedure" is not just the STCP close, it is the data flush and JS event stuff too.

Right, so those are quite different levels of "graceful":

1. Most graceful: The data channel closing procedure waits for it to "Finish sending all currently pending messages of the channel." - which can take quite a while I imagine, not something I'd expect to hold up pc.close().
2. Moderately graceful: pc.close() sends signals to the other side (RTCP BYE and SCTP ABORT) and ends immediately.
3. Ungraceful: Me yanking the network cable.

IOW channel.close() is meant to be callable as soon as you've queued all data you're going to send.

Heads up: I have changes coming to RTCDataChannel-close.html in https://github.com/web-platform-tests/wpt/pull/23737.

I'm having them reviewed there since our wpt repo is outdated, to avoid tripping up the google folks like bug 1636548 did.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #13)

Right, so those are quite different levels of "graceful":

1. Most graceful: The data channel closing procedure waits for it to "Finish sending all currently pending messages of the channel." - which can take quite a while I imagine, not something I'd expect to hold up pc.close().
2. Moderately graceful: pc.close() sends signals to the other side (RTCP BYE and SCTP ABORT) and ends immediately.
3. Ungraceful: Me yanking the network cable.

So Chrome is almost certainly doing at most 2; simply closing the socket would take a while to be noticed, and that is not what I'm seeing. I would argue that properly closing the SCTP channel should not be surfaced as an error, since this is the expected flow when a call is ending.