Detecting ICE connection that will never connect

[ArmorDarks]

Feature Request

Problem

Under normal circumstances, in case of connection issues, the ICE connection should eventually fail. connectionstatechange event will fire, and the application will have the opportunity to do something with it.

However, if all ICE candidates error during the gathering, the connection will forever stay in a new state and connectionstatechange event will never fire.

Example:

It will be possible to produce and consume, but actually, no data will be transmitted since there's no live candidate pair.

The client can check periodically for candidate pairs in stats and timeout, but there is a better way by using RTCPeerConnection.onicegatheringstatechange event.

If ICE iceGatheringState changes to complete and connectionState is still new - that means it's a dead end unless restartIce() will be invoked. It's a good opportunity for the application to warn the user that something went wrong.

However, right now, mediasoup-client doesn't expose the iceGatheringState, nor onicegatheringstatechange handler.

Proposal

Option 1: Expose the onicegatheringstatechange event and iceGatheringState on the Transport so that application can check for it.

Option 2: Add a new Transport event which will fire on pc.iceGatheringState === 'complete' && pc.connectionState === 'new' that will indicate a connection that can't be established

Caveats

onicegatheringstatechange has good browser support. If we want to cover even more browsers, we can rely on icecandidate event and event.candidate === null, which also indicates that the gathering is finished.

[ibc]

Will address in next weeks. Too busy with many other things. Thanks.

[thebongy]

Hi @ibc , can I take this change up in a PR?

About the gatheringState, we can have an API exactly similar to the connectionState, this should be straightfoward. (Along with the backward comatibility logic using the iceCandidate event as @ArmorDarks pointed out)

As for option 2, we can discuss this further, but this can be a seperate change, as doing option 1 itself would let users implement such checks in their code.

[ibc]

Sorry @thebongy, I just got 15 minutes and did it. #276