1730827 - WebRTC cannot connect to any of the ICE servers

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect)

Description

[aboutdogs7]

Attachment: about:webrtc log with server and client codes

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Hello!
I am trying to establish WebRTC connection between server (using node-webrtc) and client (using Firefox).
Offer-answer exchanging and ICE candidates gathering are working perfectly, but when iceConnectionState sets to 'checking', after 20-30 seconds it becomes 'failed' and WebRTC errors "WebRTC: ICE failed, see about:webrtc for more details".
I attached log from about:webrtc and my server and client code.

Actual results:

Firefox cannot connect to the ICE servers.

Expected results:

Firefox should have connected to one of the ICE servers.

Comment 1

[aboutdogs7]

Attachment: about:webrtc log without codes

Comment 2

[aboutdogs7]

Attachment: Server code

Comment 3

[aboutdogs7]

Attachment: Client code

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 5

[aboutdogs7]

I have redone this with client-client connection, but WebRTC still fails on the same stage, but now giving absolutely different log.

Comment 6

[aboutdogs7]

Attachment: about:webrtc log (client-client connection)

Comment 7

[aboutdogs7]

Attachment: Server code (client-client connection)

Comment 8

[aboutdogs7]

Attachment: Client code (client-client connection)

Comment 9

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Byron, would you mind having a look at this?

Comment 10

[Byron Campen [:bwc]]

So, this code appears to be a scenario with no gUM (which means we'll be somewhat restricted on what ICE candidates we can use), and one-way trickle ICE. If the network is set up in a way that means you need TURN, and you're doing one-way trickle, you're going to have problems. For example, let's call A the endpoint that is sending trickle candidates, and B the endpoint that is not sending trickle candidates. Let us further suppose that A is behind a NAT that forces the use of TURN.

1. A creates a TURN allocation, and learns a local relay candidate (let's call this Ca).
2. A trickles Ca to B.
3. A waits to receive B's candidates, so it can set up TURN permissions for them. (Uh oh...)
4. B starts sending ICE checks to Ca from every local candidate it can. The TURN server drops all of them, because no permissions have been set up.

You will get similar results even in a case where a TURN server isn't strictly required, if A is behind a NAT that is doing address-dependent (but not port-dependent) mapping/filtering. In that scenario A needs to know B's srflx or host candidate in order to open a pinhole that B can use, but since B isn't sending candidates, all of B's STUN packets get dropped by A's NAT.

Does your scenario start working if you do trickle both ways?

Comment 11

[aboutdogs7]

It is working with two-side trickle, thank you!!