- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 15:04:37 +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()`? 🤔🤷🏼♂️ by not being a WebRTC implementation. We in fact had exactly this issue interoperating with another company's server (I suspect it was a SIP server). > > > 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. No - the ICETransport underlying object is created on SLD, I think the DTLSTransport object is too. Then they are destroyed again when they turn out not to be needed. But that is really an implementation detail - we could have created ghosts. > > > 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. But if you hang on to a reference to them, they don't disappear at all.... > > > (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. That makes sense. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1719634735 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 15:04:39 UTC