Should we close peerConnection twice in RTCIceConnectionStateClosed and RTCIceConnectionStateDisconnected
Closed this issue · 4 comments
I was tracing a bug made by my own, and I found this part that I have a question.
Should we close peerConnection twice in RTCIceConnectionStateClosed and RTCIceConnectionStateDisconnected?
Or should we have a didDisconnect function to call? Or just igore RTCIceConnectionStateDisconnected?
@allenlinli those are really good concerns, definitely that need to be re-visited, please take a look at the link @kekkokk shared and especially this one[0] that is mentioned there, there is comprehensive explanation about how the standard should work, however in my experience it might differ a little between clients and platforms and ultimately you might have to step aside a little to make it work. Not telling this is the case but this[1] is an example of it.
[0] http://w3c.github.io/webrtc-pc/#rtciceconnectionstate-enum
[1] ffdf21b
Just found clear reference here:
"disconnected":
Checks to ensure that components are still connected failed for at least one component of the RTCPeerConnection. This is a less stringent test than "failed" and may trigger intermittently and resolve just as spontaneously on less reliable networks, or during temporary disconnections. When the problem resolves, the connection may return to the "connected" state.
"closed":
The ICE agent for this RTCPeerConnection has shut down and is no longer handling requests.
ref: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/iceConnectionState
Though I not still not sure should we have two disconnect here, still.
Since I opened this PR (#75), this issue can be closed.