Closed Bug 1288995 Opened 4 years ago Closed 1 year ago

ICE failed, see about:webrtc for more details

Categories

(Core :: WebRTC, defect)

49 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1448846

People

(Reporter: mantu.nigam, Unassigned)

Details

(Whiteboard: [needinfo reporter 8/3/16])

Attachments

(3 files)

11.49 KB, text/html
Details
9.38 KB, application/vnd.tcpdump.pcap
Details
24.94 KB, text/html
Details
Attached file aboutWebrtc.html
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Steps to reproduce:

Create webrtc peer connection using firefox 49 in one system.
Create another webrtc peer connection using firefox 49 on another system.
try to establish connection getting error ICE failed, see about:webrtc for more details.
however the same thing is working in chrome 46 and chrome 51


Actual results:

getting ICE failed, see about:webrtc for more details.


Expected results:

webrtc connection should established
Component: Untriaged → WebRTC
Product: Firefox → Core
It looks like we are never getting STUN responses from the other end. A PCAP might shed some light on this.
Flags: needinfo?(mantu.nigam)
Whiteboard: [needinfo reporter 8/3/16]
I'm experimenting a very similar issue.

Just some additional pointers (for my scenario):

* happens only on Windows (10 here), Linux ok
* happens only when Firefox is the "responder" (creates an answer)
* my ICE candidates are in "frozen" state when the error message appears

If I raise the "media.peerconnection.ice.stun_client_maximum_transmit" config flag from the default 7 to 15, it works, but the media takes a lot to establish. 
This is reproducible always, on different workstations.

This happens also on 50 beta.
I am seeing this exact issue on the latest version 51.1.0 for windows and osx; linux works perfectly. I am also only testing locally at the moment on my own private network with server instance on the same box as the pub/sub and also on another networked box on the same private network; in both cases windows/mac firefox subscribe fails. 
I see this ticket is a little old, but its now relevant here again and I'll see if I can get a pcap to assist in fixing it.
STUN PCAP file for needinfo
Flags: needinfo?(mreavy)
Attached file aboutWebrtc.html
The aboutWebrtc file that goes with the pcap file
Flags: needinfo?(mreavy)
Byron -- We have a pcap and about:webrtc info now.  (See comment 4 and comment 5.)  Can you take a look?
Flags: needinfo?(docfaraday)
So, looking at the ICE log in comment 5, it looks like all the necessary checks succeeded. However, some of the checks in the other direction (with exactly the same IP/port on each side) got ICMP errors. Note in particular the STUN traffic to/from port 49156 (udp.port == 49156). You have a gremlin in your network, apparently.
Flags: needinfo?(docfaraday)
Looking more, I see a pattern. Bidirectional traffic works fine for the other three ports, until .122 tries to send a check to 162.104.234.54 and gets an ICMP error back. After that, .102 cannot reach .122 any longer. Very strange.
I can think of a few possibilities here:

1. The ICMP error is causing the socket on .122 to be closed (very, very strange)
2. There is some other network traffic that occurs at about the same time as the ICMP error that is not in the pcap that causes the socket to be closed (we've run into problems with 0-length UDP packets before, IIRC).
3. There is a firewall that decides to block incoming traffic after the check to 162.104.234.54.
Byron, I could make the entire pcap available if that will help, but I'd rather send it via pm or email as it may contain info I would not want to share with the entire world; let me know if you'd like it.
Feel free to send it my way.
Ok, with the full pcap I see no evidence of possibility #2. We handle ICMP all the time with no problems, and in this case it was invariably fatal to network connectivity. I'm leaning toward possibility #3.
For #3 what do you think could work in a situation like this where its all in a local private network range? Why does the public address even matter here or the failure to get back through it? Not sure if I explained that right; Also the only thing on my network that could be considered firewall-like would be my OnHub router.
Its also odd that 3 out of 4 of the connections work; its only the 4 that breaks due to the ICMP "through" the public IP address.
(In reply to mondain from comment #13)
> For #3 what do you think could work in a situation like this where its all
> in a local private network range? Why does the public address even matter
> here or the failure to get back through it? Not sure if I explained that
> right; Also the only thing on my network that could be considered
> firewall-like would be my OnHub router.

I'd be tempted to blame firewall software.

(In reply to mondain from comment #14)
> Its also odd that 3 out of 4 of the connections work; its only the 4 that
> breaks due to the ICMP "through" the public IP address.

That's just timing; in 3 out of 4 cases the STUN check in the other direction happens before the ICMP error.
WebRTC doesn't work for me in FF56 and FF57 beta as well.
Console output is almost always the same or similar to this:

```
ICE failed, add a STUN server and see about:webrtc for more details
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
ICE failed, your TURN server appears to be broken, see about:webrtc for more details
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
ICE failed, your TURN server appears to be broken, see about:webrtc for more details
ICE failed, add a STUN server and see about:webrtc for more details
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
Using more than two STUN/TURN servers slows down discovery
main.js:1
Using five or more STUN/TURN servers causes problems
main.js:1
ICE failed, your TURN server appears to be broken, see about:webrtc for more details
```

It happens on every webrtc app like appear.in or in google hangouts or even on webrtc test pages like https://test.webrtc.org/

Fixint this would be the main reason for me to switch from chrome.

Btw I use ArchLinux, if it makes any difference
Please open a new bug for your issue rather than piggyback on this old one. Off the top of my head I'd retry with any extensions disabled, and if still no go, verify what route chrome is using for their ICE connection. Perhaps it's something exotic that we don't support.
In Mozilla connection establishes . and suddenly the transmission stop after 2-3 seconds. The Error shows is "ICE failed, see about:webrtc for more details"

Attaching the about:webrtc logs :

Local SDP (Offer)

v=0

o=mozilla...THIS_IS_SDPARTA-63.0.1 8670572331509023896 0 IN IP4 0.0.0.0

s=-

t=0 0

a=sendrecv

a=fingerprint:sha-256 4D:2D:EF:D1:69:7C:2D:FB:C6:AE:F8:E0:BF:87:BB:4F:14:5A:8D:9F:86:B5:3E:FA:53:04:AC:3B:70:BE:D5:DE

a=group:BUNDLE 0 1

a=ice-options:trickle

a=msid-semantic:WMS *

m=audio 60796 UDP/TLS/RTP/SAVPF 109 9 0 8 101

c=IN IP4 158.69.221.198

a=candidate:0 1 UDP 92217343 158.69.221.198 60796 typ relay raddr 158.69.221.198 rport 60796

a=candidate:0 2 UDP 92217342 158.69.221.198 60799 typ relay raddr 158.69.221.198 rport 60799

a=sendrecv

a=end-of-candidates

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level

a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid

a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1

a=fmtp:101 0-15

a=ice-pwd:3a67e8be257062dec9a6986c2c1f9b79

a=ice-ufrag:cf2a7385

a=mid:0

a=msid:{2df95d60-d755-4870-b293-83754b2a1508} {983efcda-592c-4f76-8db8-d4f3075e1f1d}

a=rtcp-mux

a=rtpmap:109 opus/48000/2

a=rtpmap:9 G722/8000/1

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=setup:actpass

a=ssrc:1238927400 cname:{3d6b2845-5760-4228-8dc0-b82930e23ba1}

m=video 60796 UDP/TLS/RTP/SAVPF 120 121 126 97

c=IN IP4 158.69.221.198

a=sendrecv

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:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1

a=fmtp:120 max-fs=12288;max-fr=60

a=fmtp:121 max-fs=12288;max-fr=60

a=ice-pwd:3a67e8be257062dec9a6986c2c1f9b79

a=ice-ufrag:cf2a7385

a=mid:1

a=msid:{2df95d60-d755-4870-b293-83754b2a1508} {d1234ccd-a83f-4de5-af9f-e31ba58a67fa}

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-fb:121 nack

a=rtcp-fb:121 nack pli

a=rtcp-fb:121 ccm fir

a=rtcp-fb:121 goog-remb

a=rtcp-fb:126 nack

a=rtcp-fb:126 nack pli

a=rtcp-fb:126 ccm fir

a=rtcp-fb:126 goog-remb

a=rtcp-fb:97 nack

a=rtcp-fb:97 nack pli

a=rtcp-fb:97 ccm fir

a=rtcp-fb:97 goog-remb

a=rtcp-mux

a=rtpmap:120 VP8/90000

a=rtpmap:121 VP9/90000

a=rtpmap:126 H264/90000

a=rtpmap:97 H264/90000

a=setup:actpass

a=ssrc:202140445 cname:{3d6b2845-5760-4228-8dc0-b82930e23ba1}

Remote SDP (Answer)

v=0

o=mozilla...THIS_IS_SDPARTA-63.0.1 3033569693231869061 0 IN IP4 0.0.0.0

s=-

t=0 0

a=sendrecv

a=fingerprint:sha-256 71:86:56:E7:D0:CF:C5:BC:DC:1A:EC:CE:6C:7F:33:2A:5A:47:DE:80:EE:44:64:54:8A:C9:17:A2:04:DE:34:F3

a=group:BUNDLE 0 1

a=ice-options:trickle

a=msid-semantic:WMS *

m=audio 9 UDP/TLS/RTP/SAVPF 109 101

c=IN IP4 0.0.0.0

a=candidate:0 1 UDP 92217343 158.69.221.198 60800 typ relay raddr 158.69.221.198 rport 60800

a=sendrecv

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid

a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1

a=fmtp:101 0-15

a=ice-pwd:61ffb4ffbe0d04266276f1ef3fb9d993

a=ice-ufrag:0e3a9fc2

a=mid:0

a=msid:{60f3bcb2-cf93-4ef0-8006-d1fa45ab1be7} {f5403b0b-d3b0-475c-95eb-934cfed287cf}

a=rtcp-mux

a=rtpmap:109 opus/48000/2

a=rtpmap:101 telephone-event/8000

a=setup:active

a=ssrc:1858083852 cname:{72a87a88-e2fd-40e3-9309-ca7c2de81b50}

m=video 9 UDP/TLS/RTP/SAVPF 120

c=IN IP4 0.0.0.0

a=sendrecv

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:61ffb4ffbe0d04266276f1ef3fb9d993

a=ice-ufrag:0e3a9fc2

a=mid:1

a=msid:{60f3bcb2-cf93-4ef0-8006-d1fa45ab1be7} {8a271ea4-917f-4d6b-9300-91181c6c5fdc}

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:1565598007 cname:{72a87a88-e2fd-40e3-9309-ca7c2de81b50}

RTP Stats
outbound_rtcp_video_1

Local: 10:12:03 GMT+0530 (India Standard Time) inbound-rtp SSRC: 202140445 Received: 646 packets (492.91 Kb) Lost: 3 Jitter: 0.009
inbound_rtp_audio_2

Jitter-buffer delay: 27 ms

Local: 14:44:45 GMT+0530 (India Standard Time) inbound-rtp SSRC: 1858083852 Received: 141 packets (16.72 Kb) Lost: 8 Jitter: 0.003
inbound_rtp_video_3

Decoder: Avg. bitrate: 0.03 Mbps (0.13 SD) Avg. framerate: 8.43 fps (2.33 SD)

Local: 14:44:45 GMT+0530 (India Standard Time) inbound-rtp SSRC: 1565598007 Received: 170 packets (165.31 Kb) Lost: 11 Jitter: 0.021

Remote: 10:12:03 GMT+0530 (India Standard Time) outbound-rtp SSRC: 1565598007 Sent: 138 packets (119.95 Kb)
outbound_rtp_audio_0

Local: 14:44:45 GMT+0530 (India Standard Time) outbound-rtp SSRC: 1238927400 Sent: 1449 packets (171.22 Kb)
outbound_rtp_video_1

Encoder: Avg. bitrate: 0.10 Mbps (0.04 SD) Avg. framerate: 7.66 fps (2.57 SD) Dropped frames: 10

Local: 14:44:45 GMT+0530 (India Standard Time) outbound-rtp SSRC: 202140445 Sent: 448 packets (361.32 Kb)

Remote: 10:12:03 GMT+0530 (India Standard Time) inbound-rtp SSRC: 202140445 Received: 646 packets (492.91 Kb) Lost: 3 Jitter: 0.009
inbound_rtcp_video_3

Local: 10:12:03 GMT+0530 (India Standard Time) outbound-rtp SSRC: 1565598007 Sent: 138 packets (119.95 Kb)



Please Help
(In reply to Hashim from comment #18)
> 
> 
> Please Help

Please open a new bug; the root cause is probably different, even though the symptom (ICE failed, see about:webrtc for more details) is the same.

So, looking over this, it seems likely that this is a dupe of bug 1448846.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Flags: needinfo?(mantu.nigam)
Resolution: --- → DUPLICATE
Duplicate of bug: 1448846
You need to log in before you can comment on or make changes to this bug.