webrtc: race condition during connection negotiation

When exchanging ICE candidates, the connectionStatus of one side becomes connected before the other.

At that point it closes the signalling stream (at the moment - see #580)

If this happens before it's sent its final ICE candidate, the remote's end of the stream can close mid-read and the remote's RTCPeerConnection may still have the connectionStatus of connecting.

This is handled in js by waiting for the connectionStatus of the RTCPeerConnection to change within a time out when the stream closes, even mid-read but is not reset. It works but it feels a bit hacky.

It's necessary in JS because the receiving of ICE candidates and the changes of connectionStatus on the local RTCPeerConnection are async and decoupled so may occur in any order.

Do we care about this or would it be better to add an additional, final message that can be sent over the signalling stream when one side's RTCPeerConnection becomes connected like SDP_COMPLETE or similar?

This message would mean 'this end is "connected", no more ICE candidates will be sent, the stream can/will be closed, and you should wait for your end to become "connected" or to time out'.

cc @sukunrt @mxinden @marten-seemann

Start by reading the existing signalling-stream behavior described in #580 and the issue's ICE-candidate and RTCPeerConnection sequence. Compare the current JavaScript timeout workaround with the proposed final signalling message, then define which protocol behavior should be specified and how both connection states should complete before the stream closes.