1297158 - ICE gathering never completes with unreachable STUN/TURN servers

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[Nils Ohlmeier [:drno]]

If the iceServers contain a STUN TCP or TURN TCP server which never responds to TCP SYN packets gathering never finishes.

Comment 1

[Nils Ohlmeier [:drno]]

Attachment: Bug 1297158: added a timeout for TCP connection to speed up gathering

Review commit: https://reviewboard.mozilla.org/r/73418/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/73418/

Comment 2

[Nils Ohlmeier [:drno]]

This also falls into the bucket "report TCP errors upstream faster in nICEr". Currently the over all timeouts catch this. Storing the code here in case we want to pick it up at some later point.

Comment 3

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.

Comment 4

[Byron Campen [:bwc]]

This problem is not limited to TCP. While we set up retransmissions for getting srflx candidates, and setting up relay candidates, we never set up any kind of timeout. So, if the STUN/TURN server is non-responsive, and no socket errors occur, gathering never completes.

It turns out that this bug is causing the NAT tests to time out when using a separate process for mtransport due to the interaction with:

A) the fact that IPV6 is broken in the test TURN server
B) the fact that IPV6 DNS resolution seems to be broken in the e10s code (at least for localhost, which is why we have not noticed problem A)
C) the fact that these tests disable trickle ICE on one side of the call to make candidate selection more predictable