1546562 - ICE Restart fails when re-negotiating after ICE failure.

Status: VERIFIED FIXED

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

Description

[Manjesh Malavalli]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Steps to reproduce:

1. Open the JSFiddle: https://jsfiddle.net/26cu8xsL/ in a new tab
2. Ensure that the remote video is being played back
3. Open JavaScript console
4. Turn Wi-Fi off
5. When "ICE failed" is logged in the console, turn Wi-Fi on
6. Wait for re-negotiation with ICE restart to be complete

Actual results:

ICE connection does not recover and video remains frozen

NOTE: The JSFiddle works in Chrome 73 and Safari 12.1

Expected results:

ICE connection should recover and the frozen video should resume

Comment 1

[Nils Ohlmeier [:drno]]

Actually ICE does re-connect, but RTP packets are not being send.

Byron any idea what could be going on here?

Comment 2

[Byron Campen [:bwc]]

Maybe the media engine need to be poked when this happens... I'll look into it.

Comment 3

[Byron Campen [:bwc]]

This seems to be due to the various state transition checks in the TransportLayer subclasses. Let me see what I can do about this.

Comment 4

[Manjesh Malavalli]

Nils, Byron,

I have a couple of new observations.

1. In step 4 of the reproduction steps, instead of turning off the Wi-Fi, if you switch to a different network, then
   ICE keeps failing after each ICE restart (ICE failed -> re-negotiate with ICE Restart -> ICE failed ... and so on).

2. Sometimes, I don't see "ICE failed" at all after "ICE disconnected".

Thanks,

Manjesh

Comment 5

[Manjesh Malavalli]

Nils, Byron,

One more thing:

Regarding point no. 1 in the previous comment, SDPs after ICE Restart seem to only have one TCP host candidate and no UDP candidates. Here is an example:

v=0
o=mozilla...THIS_IS_SDPARTA-66.0.3 4828696970660798509 3 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 08:B8:51:21:C7:FC:B6:58:69:11:41:20:12:84:EA:2F:80:1C:B7:73:10:F9:BA:47:3D:BE:34:A3:11:9B:ED:DD
a=group:BUNDLE 0
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 57992 UDP/TLS/RTP/SAVPF 120
c=IN IP4 10.20.16.54
a=candidate:1 1 TCP 2105524479 10.20.16.54 9 typ host tcptype active
a=recvonly
a=end-of-candidates
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:fdc2bdbcd28d1d12b37c5bd24800973f
a=ice-ufrag:406e601f
a=mid:0
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=setup:active
a=ssrc:77309501 cname:{ef7d61cc-ed03-d54a-81fd-923afaaac38b}

Thanks,

Manjesh

Comment 6

[Byron Campen [:bwc]]

Attachment: Bug 1546562: Teach TransportLayerDtls and TransportLayerSrtp to cope when TransportLayerIce fails, and then recovers. r?mjf

Depends on D28839

Comment 7

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=508259d25307ead6893747f4cd9b7c737a159e95

Comment 8

[Byron Campen [:bwc]]

Try looks good.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d8aabb749462
Teach TransportLayerDtls and TransportLayerSrtp to cope when TransportLayerIce fails, and then recovers. r=mjf

Comment 10

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/d8aabb749462

Comment 11

[Anca Soncutean, Desktop QA]

I’ve reproduced this issue with Fx 68.0a1 (2019-04-23) on macOS 10.13.
The issue is verified fixed (the video resumes accordingly) with Fx 69.0a1 (2019-06-30) and Fx 68.0b14 on macOS 10.13, macOS 10.14 and Ubuntu 18.04 x64.