Healthy connections get destroyed during ice candidate negotiation

Looks like this line here sometimes destroys even healthy connections!

https://github.com/feross/simple-peer/blob/cb73f00eca78054fe57047b2bf12eb2560f25ed3/index.js#L655

It happens when connection temporary fails and ICE is still negotiating candidates.

A little intro

1. Connection in “failed” state stands for:

One or more of the ICE transports on the connection is in the “failed” state. (https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/connectionState)

But it actually also happen when iceConnectionState is “disconnected”.

1. iceConnectionState in “disconnected” state means:

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. (https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/iceConnectionState)

And what I’ve realized right now, is that actually even “failed” iceConnectionState can be recovered. So may be this line could be also somehow improved as well: https://github.com/feross/simple-peer/blob/cb73f00eca78054fe57047b2bf12eb2560f25ed3/index.js#L676

How to reproduce

So I used chrome & safari browsers. And checked connection from 2 macbooks, one connected to 3G another to wifi. I pass signals(offers/answers) manually via messenger

I’ve used turn& stun servers from Twilio as configuration

Ok. So first I create Peer with initiator:true, trickle: false, on first mac. I get offer with candidates.

On another mac then I create Peer with initiator: false, trickle: false. And then I pass offer this.peer.signal(offer). If I’ll pass answer back to initiator fast enough, connection get created. But I wait for around 15 seconds & then connection get destroyed, because iceConnectionState switches to “disconnected” or to “failed”. And that’s what is fishy. The interesting thing is that if I comment out mentioned lines then I am able to create connection even when it’s in “failed” state.

Thoughts

So this makes me think that “failed” or “disconnected” states for iceCandidates and “failed” state for connection itself don’t mean too much. It’s not a failure yet, I guess, since it can be reestablished so easily, it’s more “on hold” type of state.

I’m not really sure how the issue can be fixed, though since I’m pretty new to WebRTC myself. And all these states are confusing. It needs further experimentation

Thank you!

[kk-007]

it looks funny but i have the same issue and i solved it by changing internet connection. when i switch to mobile data from a broadband project run well and when i again switch back to broadband it gives that error. my project: https://github.com/kk-007/webrtc-video-call

[fippo]

Most routers have timeouts on address mappings, which means the connection information in the server-reflexive ICE candidates expires.

WebRTC implementations should periodically ping the STUN server to keep the mapping open, see https://tools.ietf.org/html/rfc5389#section-6. If that isn’t the case, please file a bug against the implementation!