W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

[webrtc-pc] Is close() supposed to fire state change events? Connection state change set asynchronously?

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Mon, 04 Jun 2018 13:34:50 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-329058246-1528119288-sysbot+gh@w3.org>
henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== Is close() supposed to fire state change events? Connection state change set asynchronously? ==
Supposedly, calling close() implies...
- signaling state changes to ["closed"](https://w3c.github.io/webrtc-pc/#dom-rtcsignalingstate-closed), [this is explicit](https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-close) but _no signalingstatechange event is fired_.
- ICE connection state changes to ["closed"](https://w3c.github.io/webrtc-pc/#dom-rtciceconnectionstate-closed), this is not explicit but destroying the ICE agent is.
- connection state changes to ["closed"](https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnectionstate-closed), this is not explicit but destroying the ICE agent is.

Did we simply forget to set the ICE connection state and connection state to "closed" in the spec, or is this supposed to be covered by destroying the ICE agent?

Without setting the ICE connection state and the connection state explicitly it is unclear if this is supposed to happen synchronously or asynchronously and whether or not events should fire. For example, [update ICE connection state](https://w3c.github.io/webrtc-pc/#update-ice-connection-state) is invoked _asynchronously_ [when the ICE agent indicates the state has changed](https://w3c.github.io/webrtc-pc/#rtcicetransport) and it also fires an event. But it is not clear that these steps should be executed when the ICE agent is destroyed.

Possible spec bugs:
- ICE connection state and connection state are set asynchronously, but signaling state is set synchronously.
- ICE connection state and connection state changing fires events, but signaling state changing does not.

I would think that invoking a synchronous API should set all three of these states synchronously and not fire any events.

Otherwise if it is intended that some states are updated synchronously and some are updated asynchronously it makes sense that the asynchronous changes does still fire events, but it got me a bit confused.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1883 using your GitHub account
Received on Monday, 4 June 2018 13:34:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC