Updates to RTCPeerConnection.connectionState should happen when new RTCDtlsTransports/RTCIceTransports are created and destroyed due to negotiation

[docfaraday]

Right now, it does not appear that webrtc-pc says to update RTCPeerConnection.connectionState when negotiation creates/destroys transports. So, for instance, if a reoffer adds an m-section with a new transport (ie; not in a bundle with a previously existing transport), the connectionState would need to go back to connecting. As another example, if the previously mentioned reoffer is rolled back, we would expect the connectionState to revert back to what it was before.

We need to be updating this state on reoffers, reanswers, and rollbacks at a minimum.

[fippo]

So, for instance, if a reoffer adds an m-section with a new transport (ie; not in a bundle with a previously existing transport), the connectionState would need to go back to connecting

That is a known ugly consequence, see https://jsfiddle.net/fippo/koaqs21v/ in chromium-based browsers.

[docfaraday]

So, the more I think about this, the more it seems appropriate to defer the updates to RTCPeerConnection.connectionState/iceConnectionState until the answer is set. A local offer that creates a new transport does not mean a whole lot; the transport could be negotiated away (due to bundle or an m-section rejection), rolled back, or maybe the answer never comes. It only matters once the answer is set.

Now, I can see updating the gathering state; after sLD(offer) we expect to see trickle candidates, so I would also expect to see gathering state changes.

[docfaraday]

Furthermore, I think maybe we need to ignore RTCDtls/IceTransports in "new". Suppose the following occurs:

1. ICE is in checking from a previous negotiation.
2. We do a sLD(offer) that creates a new transport. We don't bother updating the connectionState/iceConnectionState (see above comment).
3. ICE connects! The old set of transports is now ready.
4. We handle the event on the RTCIceTransport, see the new transport that we aren't using yet, and set RTCPeerConnection.iceConnectionState to "checking"!

This seems wrong.