- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 06:08:43 +0000
- To: public-webrtc-logs@w3.org
I was imagining a getter that returns all the transports currently active for the PeerConnection. When using max-bundle, there would be only one; when there are more than one, apps that care will have to find some way to sort out which is which. (Comparing the transport objects to those on the transceivers should do it). I don't know how you define "ghost" when you say that "transceivers are ghosts" - the scenario for the sctpTransport is that when the responder rejects the "m=application" media section in the remote answer, no sctpTransport underlying object will ever have been created. So the sctpTransport object that would be visible after createOffer will never correspond to a real sctpTransport - unlike rejected transceivers, which "just" transition to state "stopped" (if I remember rightly). That said, as I said in the meeting, I won't stand in the way of resolving this issue by mandating the creation of the ghost. (Does the ghost go away when it's known that it will never be created? If not, what's its state? Details, details.....) -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1718818522 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 06:08:45 UTC