My iceConnectionState changes have been reverted, so they're probably not to blame. On the other hand I intended to port the current disconnect semantics, so they won't fix this either. :)

'disconnected' is the vaguest state in the standard. We are supposed to be in it if we're not in 'closed'/'failed' and at least one ICE transport is disconnected. The 'disconnected' transport state is implementation-defined, so effectively the entire 'disconnected' state is implementation-defined.

The standard doesn't really matter here though, because we do something entirely different in webrtc. The current implementation is the hack: "If we used to be 'connected' or 'completed' but are about to become 'connecting' again, instead report 'disconnected'".

I could imagine us needlessly signalling disconnected if for some reason add new ice transports to a peerconnection whose current ice transports are already up and running. Maybe something like that is happening here?

Whether bundling is or is not used, why would any transport end up in 'disconnected' when an m= section is added? I would think that either the existing already-connected transport is used again (bundling?) or a new transport is added that is attempting to connect (non-bundling?), but in either case no transport would in any sense stop being connected.

I might mix up the different connection state types :)

My guess was that we'd end up with an old 'connected' transport and a new 'connecting' one. With a mixture of these we're supposed to be 'connecting', and the hack would replace that with 'disconnected'. No individual transport is disconnected, but we still report that as the aggregate state.

Actually, I went and double-checked. The hack is the only current implementation of 'disconnected' in webrtc, we don't base anything on information from the transports.

the new transport should be in 'new' state, no? What does that mean for the connectionState even?

new + connected/completed => new, which I disagree with. See https://github.com/w3c/webrtc-pc/issues/2031 for some talk about the PeerConnectionState, which has a similar issue.

is this for bundle-less?
with bundle, nothing should happen with transports. with bundle-less, we're adding another transport, so we could argue for "new" state when created, and "connecting" state until it connects.

what naive users will expect is that the new transport doesn't affect the overall state until it's operational, but it seems very puzzling to specify that in a sane manner (what if it never becomes operational?)

thinking: the overall state should be "new" only when all transports are "new". If some of them have progressed further, the overall state should be "connecting".

Jonas, now that the PR (https://github.com/w3c/webrtc-pc/pull/2036) has landed, what is the status of implementation and target milestone?

Once https://webrtc-review.googlesource.com/c/src/+/111964 lands I'll make a 10-lie CL in chrome to switch the ice state, and that should be it. I expect the code to land next week, so M73 unless we want to back-merge things.