webrtc/RTCDataChannel-close.html and /webrtc/RTCRtpReceiver-getSynchronizationSources.https.html are expected TIMEOUT
Categories
(Core :: WebRTC, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | affected |
People
(Reporter: jmaher, Assigned: bwc)
References
Details
Attachments
(1 obsolete file)
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?
Comment 1•4 years ago
|
||
Byron has been keeping an eye on our web-platform tests.
Assignee | ||
Comment 2•4 years ago
|
||
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
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
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.
Assignee | ||
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Ok, in the meantime some change has landed that causes these tests to fail before they time out. Looking into it.
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
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:
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.
Comment 8•4 years ago
|
||
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
Comment 9•4 years ago
|
||
ponders the normative meaning of SHOULD IF POSSIBLE
Assignee | ||
Comment 10•4 years ago
|
||
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.
Assignee | ||
Comment 11•4 years ago
|
||
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.
Assignee | ||
Comment 12•4 years ago
|
||
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.
Comment 13•4 years ago
|
||
Right, so those are quite different levels of "graceful":
- 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()
. - Moderately graceful:
pc.close()
sends signals to the other side (RTCP BYE
andSCTP ABORT
) and ends immediately. - Ungraceful: Me yanking the network cable.
Comment 14•4 years ago
|
||
IOW channel.close()
is meant to be callable as soon as you've queued all data you're going to send.
Comment 15•4 years ago
•
|
||
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.
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #13)
Right, so those are quite different levels of "graceful":
- 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()
.- Moderately graceful:
pc.close()
sends signals to the other side (RTCP BYE
andSCTP ABORT
) and ends immediately.- 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.
Description
•