Ignore USE-CANDIDATE to accommodate clients that do agressive ICE nomination

[havfo]

Feature Request

Firefox uses agressive ICE nomination when communicating with an ICE-lite peer (Mediasoup) Bugzilla. This breaks transports under certain scenarios (e.g. blocked inbound UDP, but open outbound UDP). This is not the correct behaviour from Firefox, but it seems this will not be fixed in the forseable future, and it would be beneficial to have Firefox not be at a disadvantage if possible.

A proposal for a solution is to ignore USE-CANDIDATE from the client and just use the last valid tuple instead. This would fix Firefox and should not impact other browsers.

A simple POC I did (I removed the code blocks that check USE-CANDIDATE in all the switch cases like this one: hasUseCandidate) shows it to have seemingly fixed Firefox and didn't break Chrome.

A problem with this approach is that you would loose the distinction between the ICE CONNECTED and COMPLETED states. As far as my cursory glance at the code base can reveal, this should not impact any code paths within the worker code, but I could be wrong here.

[ibc]

Reminder for @jmillan and me to take a look to this.

[jimying]

I ran into this problem recently, firefox webrtc can not work in some network scene, but use ice-relay can work. (The webrtc server side use ice-lite)

I have an idea : When receive stun binding request first time and contains USE-CANDIDATE, after stun response, mark it as pending nominate.

Then send stun binding to peer, only when receive response ok, set state to nominated.

It should work for firefox/chrome/safari. The disadvantage is that there will be a little delay(one more trip)