Issue metadata
Sign in to add a comment
|
closing remote RTCPeerConnection no longer closes local datachannels
Reported by
useru...@gmail.com,
Sep 11
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Steps to reproduce the problem: 1. Connect two webrtc peers 2. Create a datachannel between the peers 3. Log the datachannel onclose event for the local datachannel 4. Close the remote RTCPeerConnection object using the .close() method What is the expected behavior? When the remote RTCPeerConnection is closed the local datachannels should close and call the onclose event. What went wrong? The local datachannel is never closed. Did this work before? Yes 68 Does this work in other browsers? Yes Chrome version: Version 69.0.3497.81 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 30.0 r0 I'm not sure of what the webrtc specs says about this, but it datachannels were closing as described up to chrome version 68 and they also do in Firefox. It was useful for detecting when a connection had been closed. Here's a jsfiddle demostrating the issue (same code as the attached js file): https://jsfiddle.net/cgdpusy0/3/ It creates two RTCPeerConnection and a pair of negotiated datachannels between them, then one second later one RTCPeerConnection is closed. In chrome 69 only pc1dch will be closed.
,
Sep 11
Spec says, under "close" on an RTCPeerConnection: * Set the [[ReadyState]] slot of each of connection's RTCDataChannels to "closed" NOTE The RTCDataChannels will be closed abruptly and the closing procedure will not be invoked. * If the connection's [[SctpTransport]] is not null, tear down the underlying SCTP association by sending an SCTP ABORT chunk and set the [[SctpTransportState]] to "closed". The reception of the ABORT chunk is in section 6.1.2, description of SCTP closed state: closed - A task is queued to update the [[SctpTransportState]] slot to "closed" when a SHUTDOWN or ABORT chunk is received or when the SCTP association has been closed intentionally, such as by closing the peer connection or applying a remote description that rejects data or changes the SCTP port. I don't see any text saying what effect, if any, these events should have on the datachannel state. That's probably a spec bug.
,
Sep 11
I found the following in the spec section 6.2
When an RTCDataChannel object's underlying data transport has been closed, the user agent MUST queue a task to run the following steps:
Let channel be the RTCDataChannel object whose transport was closed.
Set channel's [[ReadyState]] slot to closed.
If the transport was closed with an error, fire an event named error using the RTCErrorEvent interface with its errorDetail attribute set to "sctp-failure" at channel.
Fire an event named close at channel.
,
Sep 11
,
Sep 12
hbos@: Can you take a look or triage further?
,
Sep 12
As per comment#2, the root cause of the issue seems to be identified. Hence removing Needs-Bisect label and ccing hta@ to give for further inputs on the issue. Note: Please feel free to add the Needs-bisect label back if this still requires to bisect. Thanks.!
,
Sep 12
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by philipp....@googlemail.com
, Sep 11