1698972 - ICE pair state transition from FAILED to WAITING when no Triggered Check was sent

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect)

Description

[Michał Kasiński]

Attachment: log_filtered.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36

Steps to reproduce:

In my scenario I have a webrtc peer A running on Firefox that have only one local ICE candidate(privateIP_A), and a remote peer B that have only one ICE candidate (publicIP_B) with Lite ICE implementation (FreeSWITCH).
Peer A receives a candidate from peer B, and forms one pair (privateIP_A/publicIP_B) to start connectivity check. During connectivity check as peer A is behind NAT, it forms a new candidate type prflx and a new pair (publicIP_A/publicIP_B), and set first pair to state FAILED.

Actual results:

Connectivity check on a prflx pair (publicIP_A/publicIP_B) ends with state SUCCEED but suddenly checks on a first pair restart.
Firefox mistakenly log that it received a STUN check on a failed pair which is not possible as Lite ICE agent did not generate any checks.

Expected results:

Once firefox marked pair as FAILED it should not resurrect it if no triggered check was sent from peer B.

Comment 1

[Michael Froman [:mjf]]

This looks webrtc::networking. Byron, do you have time to take a quick look?

Comment 2

[Michał Kasiński]

Comment on attachment 9209572 [details]
log_filtered.txt

>setting pair to state FROZEN: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state WAITING: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state IN_PROGRESS: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state FROZEN: VJmr|IP4:178.235.185.121:7626/UDP|IP4:37.130.6.14:25900/UDP(prflx|candidate:9596795817 1 udp
>setting pair to state FAILED: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state SUCCEEDED: VJmr|IP4:178.235.185.121:7626/UDP|IP4:37.130.6.14:25900/UDP(prflx|candidate:9596795817 1 udp
>received STUN check on failed pair, resurrecting: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817
>setting pair to state WAITING: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state IN_PROGRESS: CavB|IP4:192.168.0.10:57453/UDP|IP4:37.130.6.14:25900/UDP(host(IP4:192.168.0.10:57453/UDP)|candidate:9596795817 1 udp
>setting pair to state SUCCEEDED: VJmr|IP4:178.235.185.121:7626/UDP|IP4:37.130.6.14:25900/UDP(prflx|candidate:9596795817 1 udp

Comment 3

[Michał Kasiński]

Attachment: log_filtered_v2.txt

Comment 4

[Byron Campen [:bwc]]

I'm going to need a packet capture to make absolutely sure we did not receive a STUN request from the other end here, because I do not see how we could have ended up in this code path otherwise.

Comment 5

[Michał Kasiński]

Closer look to a pcap shown that there was triggered check sent some time later.
Unfortunately logs in about:webrtc have no timestamps which is some inconvenience in diagnostics, especially in complexity of ICE.