Closed Bug 1546562 Opened 8 months ago Closed 8 months ago

ICE Restart fails when re-negotiating after ICE failure.

Categories

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

65 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox68 --- verified

People

(Reporter: mmalavalli, Assigned: bwc)

References

()

Details

(Keywords: parity-chrome, parity-safari, testcase)

Attachments

(1 file)

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

Has STR: --- → yes
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core

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

Byron any idea what could be going on here?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(docfaraday)
Priority: -- → P2

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

Assignee: nobody → docfaraday
Flags: needinfo?(docfaraday)

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

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

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

Try looks good.

Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d8aabb749462
Teach TransportLayerDtls and TransportLayerSrtp to cope when TransportLayerIce fails, and then recovers. r=mjf
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.