- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Sep 2023 20:26:20 +0000
- To: public-webrtc-logs@w3.org
@steely-glint introduced the term "ghost", which I interpreted to mean an object that, if rejected or BUNDLED away by the other side, only exists during negotiation (or in the case of transceivers, until a negotiation initiated by the other side).
The proposal here is to align the sctpTransport's lifetime with that of its iceTransport, which acts as @alvestrand describes, which I find quite ghostly, but regardless.
I wrote [this fiddle](https://jsfiddle.net/jib1/wx8d5jv2/) to reject m=application and found quite inconsistent behavior in browsers (bugs maybe?) But all of the browsers seem to fire ice candidates on initial negotiation only, so we might only need to expose this `pc.sctp` ghost once, and not on every renegotiation which is a relief.
Datachannel rejection seems like an edge-case. But how are apps to learn of it? Might early exposure help here? E.g.
```js
pc.createDataChannel("");
await pc.setLocalDescription();
pc.sctp.onstatechange = () => pc.sctp.state == "closed" && console.log("m=application rejected!");
// continue negotiation
```
I find support for this in the description of the "[closed](https://w3c.github.io/webrtc-pc/#idl-def-RTCSctpTransportState.closed)" state: _"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."_
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1724318199 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 18 September 2023 20:26:22 UTC