No DTLS/SCTP shutdown procedure when tab is closed (or Chrome is quit:ed) for PeerConnection with datachannel
Reported by
and...@lonelycoder.com,
Feb 6 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Setup a WebRTC PeerConnection to a peer. 2. Close the Tab What is the expected behavior? DTLS Alert and/or SCTP Abort should be sent by Chrome. What went wrong? Did not receive and shutdown notification. See attached file (with protocol dumps). Displays packets exchanged both when using Chrome and Firefox. Did this work before? No Does this work in other browsers? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: Shockwave Flash 24.0 r0 Chrome does shutdown the WebRTC connection when my laptop lid is closed (as expected I suppose) I've not done any additional testing when using WebRTC with video or audio channels as data is my primary concern.
,
Feb 6 2017
,
Feb 6 2017
I confirmed that this is an issue, though I'm putting it at a lower priority since these notifications aren't reliable (being transmitted over UDP).
,
Feb 7 2017
,
Feb 9 2017
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Setup a WebRTC PeerConnection to a peer. 2. Close the Tab What is the expected behavior? DTLS Alert and/or SCTP Abort should be sent by Chrome. What went wrong? Did not receive and shutdown notification. See attached file (with protocol dumps). Displays packets exchanged both when using Chrome and Firefox. Did this work before? No Does this work in other browsers? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: Shockwave Flash 24.0 r0 Chrome does shutdown the WebRTC connection when my laptop lid is closed (as expected I suppose) I've not done any additional testing when using WebRTC with video or audio channels as data is my primary concern.
,
Feb 14 2017
A side-effect of this problem is that the auto-sleep function of host O.S. won't kick in if you closed a tab that had a webRTC peerconnection. You pretty much have to shut down all chrome tabs. (Or do not close the tab and instead navigate that tab to a website that doesn't make any webRTC connections.)
,
Feb 14 2017
,
Feb 18 2017
fwiw I highly disagree with this being p3, as it prevents sleep on devices that should otherwise be sleeping. This was not an issue before either. Looks like the initial report was on OSX, this is happening on Windows 10 as well.
,
Feb 18 2017
,
Feb 18 2017
The sleep-related issue seems unrelated to not sending DTLS alert/SCTP abort packets. Here's a new issue: https://bugs.chromium.org/p/chromium/issues/detail?id=693804
,
Feb 18 2017
The sleep issue was recently fixed in issue 612294
,
Mar 24 2017
Chrome version: 59.0.3050.3 canary (64-bit) still have this bug. you can open https://aixuexi.tmall.com/?ali_trackid=17_802f2a00025e4fd75b683ed4d94c923e when this tab open, use "pmset -g assertions" result: pid 52034(Google Chrome Canary): [0x0003a64d0001858e] 00:02:59 NoIdleSleepAssertion named: "WebRTC has active PeerConnections"
,
Mar 24 2017
This bug is specifically about DTLS/SCTP shutdown procedures, not general sleep issues. Let's discuss this on issue 612294 .
,
Sep 27 2017
Should we keep this bug open, or archive it?
,
Sep 27 2017
It still exists as far as I'm aware.
,
Aug 13
Still exist in version 68.0.3440.106. Running my outlook.com in Edge instead. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by and...@lonelycoder.com
, Feb 6 201713.1 KB
13.1 KB View Download