- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 14:32:50 +0000
- To: public-webrtc-logs@w3.org
> when the responder rejects the "m=application" media section in the remote answer ... Not to branch out too many new topics, but how would an app do that (in the API?) `pc.sctp.stop()`? 🤔🤷🏼♂️ > So the sctpTransport object that would be visible after createOffer will never correspond to a real sctpTransport - This would match how the other transports work. > unlike rejected transceivers, which "just" transition to state "stopped" (if I remember rightly). Rejected transceivers eventually disappear from getTransceivers() — we just kludged it to require an offer from the remote side first to avoid apps accidentally nuking the offerer-tagged BUNDLE transport. > (Does the ghost go away when it's known that it will never be created? If not, what's its state? Details, details.....) Same as with the other transports. They stop being referenced by the pc, so the app can no longer find them. But of course JS can hold any object alive, so its states are still observable and need to make sense. It's state would be [closed](https://w3c.github.io/webrtc-pc/#idl-def-RTCSctpTransportState.closed) I imagine. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1719572967 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 14:32:52 UTC