- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Sep 2023 21:09:06 +0000
- To: public-webrtc-logs@w3.org
> ... a way to get the transport that worked for all cases independent of whether there was SCTP ... > The sticker here is really what to return for non-bundled connections. Agree this might've worked if "[max-bundle](https://w3c.github.io/webrtc-pc/#dom-rtcbundlepolicy-max-bundle)" was all we needed to support. But the current API surface shape also supports "[balanced](https://w3c.github.io/webrtc-pc/#dom-rtcbundlepolicy-balanced)" and "[max-compat](https://w3c.github.io/webrtc-pc/#dom-rtcbundlepolicy-max-compat)". > adding a member to the pc.oniceconnectionstatechange data that is the iceTransport that it relates to This has the same problem Harald raises: what to return for non-bundled connections? I also thought we introduced the ORTC-like transport objects to get away from relying on the aggregated pc states, so building on the aggregated state feels like the wrong direction. > I don't like surfacing a (potentially ghost) sctpTransport who's values are wrong or non-existent just to get an iceTransport. Aren't transceivers also ghosts by this definition? I don't think its values are more wrong than those of DtlsTransport: they reflect what the local offer is about to negotiate. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2899#issuecomment-1718320913 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 September 2023 21:09:12 UTC