reconnection not possible

[yocontra]

seems like this library treats closed and disconnected ICE states as destroyed, but disconnected can also mean that it was temporarily disconnected and is attempting to reconnect. we are seeing increased connection drops since switching to simple-peer since there is no way to let the peer run its natural reconnection processes

https://github.com/feross/simple-peer/blob/master/index.js#L324

[feross]

Just released v5.6.0 which doesn't destroy the Peer object when ICE becomes 'disconnected'. Let me know if that reduces the number of connection drops you're seeing.

[yocontra]

testing it now, will let you know if it allows our reconnect logic to kick in

[feross]

Any update?

[yocontra]

Working smoothly again! In case anybody sees this later and is wondering - for reconnection set a timeout on disconnect to destroy unless connect has been emitted again.

@feross What do you think about an option for this?

[feross]

@contra Yes, this should be built into simple-peer. I'm noticing that sometimes the 'disconnect' ICE state happens, but never 'closed', so the peer never fires 'close' and lives on as a zombie. Adding a timer into instant.io would allow 'close' to eventually fire and give reconnect a chance to happen.

[codealchemist]

Hi guys!
After connecting two peers if I reload the second one I get this error on the initiator:
Error: InvalidStateError: Failed to set remote answer sdp: Called in wrong state: kStable

The peer connection and the data channel objects are destroyed.
How do you suggest handling this scenario?

Thanks!

[nazar-pc]

@codealchemist, apparently not, otherwise it wouldn't be in wrong state: kStable.
Look at your code again and make sure to actually destroy the instance and create a new one for re-created connection. WebRTC is tricky and sometimes you may get an issue that is not very obvious, but there should be one somewhere.

[codealchemist]

Thanks for your answer @nazar-pc.
I'll continue debugging.

Cheers!