W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2016

[webrtc-pc] pc.close() never fires any events. On purpose?

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Mar 2016 04:06:00 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-144458114-1459310759-sysbot+gh@w3.org>
jan-ivar has just created a new issue for 

== pc.close() never fires any events. On purpose? ==
 never [updates the ICE connection 
state](http://w3c.github.io/webrtc-pc/#update-ice-connection-state) to
 `"closed"`, and never fires a simple event named 
 at *connection* with `"closed"`. Intentional?

The spec seems unclear:

The text on 
 says "The signaling state has changed. This state change is the 
result of either setLocalDescription() or setRemoteDescription() being
 invoked. " (which seems to exclude close).

But then the explanation for [*onsignalingstatechange* said until 
 (the removal seems editorial): "It is called any time the 
RTCPeerConnection signaling state changes, i.e., from a call to 
setLocalDescription, a call to setRemoteDescription, or code. It does 
not fire for the initial state change into new." (which seems to 
suggest it fires for `"closed"`).

If they are to fire, I have questions about whether they're to fire 
synchronously (in which case we need to deal with reentrancy), or 
whether they are to be queued in a task, and if the latter whether the
 setting of the state is to be queued as well.

Arguably, with the merge of https://github.com/w3c/webrtc-pc/pull/552 
there is no need to fire these anymore, since the peer connection will
 never close on you.

Looking for clarification.

Please view or discuss this issue at 
https://github.com/w3c/webrtc-pc/issues/565 using your GitHub account
Received on Wednesday, 30 March 2016 04:06:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC