Error: Ice connection failed

[ghost]

Pinned Troubleshooting

This error is caused by a failure to find a viable network route through ICE. The following steps will help you debug common causes of the error.

1. You have found a bug that is already patched in simple-peer source.

   • Try the latest source code for simple-peer (not the latest npm release).

2. Your STUN or TURN servers are not configured properly.

   • Ensure you can connect to your STUN/TURN servers with this tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
   • Ensure you receive at least one relay candidate (from the TURN server).
   • Make sure you are using urls and not url in the iceServers config.
   • You specified a config object with no iceServers.
   • Try using your own STUN servers instead of default/public ones (which can be unreliable).

3. There is a problem with your signalling channel.

   • Ensure latency on signalling messages is not too high (above 10 seconds).
   • Ensure all signal messages are being delivered.

4. Your firewall or internet provider is blocking WebRTC traffic.

   • Try disabling your firewall first, if it works, test the following:
   • Append "?transport=tcp" to your TURN config to avoid UDP rules.
   • Configure your TURN server to use port 443 to avoid port rules.
   • Use TLS over TCP to avoid packet analysis rules.
   • You WILL NOT need to disable firewalls in production.

5. You have found a new bug, or a rare case we haven't discussed here.

   • Opening a NEW issue, mentioning you've completed the above steps, and providing a link to a relatively brief and filtered .pcap file is the only way anyone can help you further. https://webrtc.org/testing/wireshark/

Original Issue

Hi, I am trying to make a connection with simple-peer. One side is on node & other side is on chrome. Normally everything is OK. But When one side is switch to phone internet I get "Error: Ice connection failed" error. I have a turn server & using for iceServer config. Any idea how to fix or debug that?

Thanks.

[vbgm]

+1, have the same issue

It might be related to https://github.com/webrtc/adapter/issues/661 and ICE Candidates Restrictions: https://webkit.org/blog/7763/a-closer-look-into-webrtc/

[kifhan]

Have you tried reconnectTimer option? It makes Simple-peer attempt reconnect before emitting 'close'.

[vbgm]

I have tried the reconnectTimer (set to 3000ms) it just tries one more time to reconnect (as expected) and still the same error at the end. As well tried in Safari's 'Develop > WebRTC' menu 'Disable ICE candidates restrictions' - the same error.

Btw, the signalling data exposed and sent (over separate websockets connection) contains real IP address of the peer on the mobile device, and is successfully received on desktop peer. So it might be not the issue with the ICE Candidates Restrictions.

Tried Safari 11 desktop and on iOS 11.

[vbgm]

I have tried a custom STUN/TURN server and managed to fix the error.

[ghost]

Here is what I have tried; I am using phone's internet sharing on my pc;

With an Android phone I could connect over relay server but with an iPhone I could not get a connection. Then I forced to work with relay with iceTransportPolicy: "relay" option. Now with iPhone I can connect but can not connect over normal network.

Also tried reconnectTimer:8000 Nothing changed.

Any idea?

[fabioaccetta]

@vblagomir: please, can you share your custom STUN/TURN configuration? Or give us some hint to work on to solve the problem?

[vbgm]

@fabioaccetta As a test I have created a stun/turn server here: http://numb.viagenie.ca and it worked.. now figuring out how to run my own..

[ghost]

@vblagomir Did you tried to connect by using iPhone (Shared Connection)?

[vbgm]

So far I have entered following into ice servers list:

   {
      "urls": "stun:numb.viagenie.ca",
      "username": “some@email.com",
      "credential": “somepassword”
    },
    {
      "urls": "turn:numb.viagenie.ca",
      "username": "some@email.com",
      "credential": "somepassword"
    }

and managed to establish a data channel between iPhone iOS11 (connected in 3G network) and my local computer with Safari 11.0. But this is temporary and sort of proof of concept. Normally one should set up his/her own Turn/Stun server.

[MaciejWWojcik]

I have the same problem as You @doganmurat a few days ago. Finally I have repair this, and the config of simplePeer that works in my app is this:

const peer = new SimplePeer({
      initiator: true,
      stream: this.videoStream,
      reconnectTimer: 100,
      iceTransportPolicy: 'relay',
      trickle: false,
      config: {
        iceServers: [
          {
            "urls": "stun:numb.viagenie.ca",
            "username": '******@gmail.com',
            "credential": '****'
          },
          {
            "urls": "turn:numb.viagenie.ca",
            "username": "****@gmail.com",
            "credential": "*******"
          }
        ]
      }
    });

[ghost]

Hi @MaciejWWojcik ,

Please see my comment above. If you force simple-peer to use relay server, then somehow you can not connect over normal network. Could you please try this as well?

[ibudisteanu]

I can not make the Simple Peer to connect. It shows me the above-mentioned error. Is it because we use Simple-Peer? I suspect, this error was created during the new releases. Moreover, even the Simple-Peer Demo source code cannot work on two different computers from two different networks. I tried all the above suggestions, and absolutely none of them worked for me. I tried dozens of iceServers as well. Any suggestions of how you made it work? You can check my application on my website

The error I receive

Error: Ice connection failed.
    at Peer._onIceStateChange

I can make it only working on localhost (multiple tabs) and in a local network (different computers), but in the same local network. In the local network, I was able to connect between local computers and local browsers from Chrome, Firefox.

The signals look ok for me. Moreover, when the connection is trying to establish, the Ice connection fail error appears on both browsers, so somehow the connection is being initialized, but then it throws the above-mentioned exception.

 { type: 'offer',
     sdp: 'v=0\r\no=- 799787221816349767 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE data\r\na=msid-semantic: WMS\r\nm=application 60755 DTLS/SCTP 5000\r\nc=IN IP4 5.12.206.160\r\na=candidate:2020300070 1 udp 2113937151 192.168.2.8 60755 typ host generation 0 network-cost 50\r\na=candidate:842163049 1 udp 1677729535 5.12.206.160 60755 typ srflx raddr 192.168.2.8 rport 60755 generation 0 network-cost 50\r\na=ice-ufrag:5vLE\r\na=ice-pwd:BZlSkfOQOpzGTamZi1cEWzsR\r\na=fingerprint:sha-256 75:4E:FC:88:55:97:F1:D1:C2:26:88:C3:82:1C:5C:87:DF:DF:C9:90:90:A6:F5:3A:A0:6F:A6:7D:4C:83:B9:77\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n' } }

   { type: 'answer',
     sdp: 'v=0\r\no=- 3314710403443195041 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE data\r\na=msid-semantic: WMS\r\nm=application 63152 DTLS/SCTP 5000\r\nc=IN IP4 86.126.104.54\r\nb=AS:30\r\na=candidate:2702239670 1 udp 2113937151 192.168.1.103 63151 typ host generation 0 network-cost 50\r\na=candidate:842163049 1 udp 1677729535 86.126.104.54 63152 typ srflx raddr 192.168.1.103 rport 63151 generation 0 network-cost 50\r\na=candidate:842163049 1 udp 1677729535 86.126.104.54 63154 typ srflx raddr 192.168.1.103 rport 63151 generation 0 network-cost 50\r\na=candidate:842163049 1 udp 1677729535 86.126.104.54 63153 typ srflx raddr 192.168.1.103 rport 63151 generation 0 network-cost 50\r\na=candidate:842163049 1 udp 1677729535 86.126.104.54 63156 typ srflx raddr 192.168.1.103 rport 63151 generation 0 network-cost 50\r\na=ice-ufrag:3Cvy\r\na=ice-pwd:jS/ZJ29MKW/09l/6SIE6+Nr9\r\na=ice-options:trickle\r\na=fingerprint:sha-256 79:3B:38:E8:90:4F:20:26:C1:8C:9A:2C:00:2E:DC:E9:D6:E1:AA:87:31:01:B8:FD:0B:EE:DD:07:20:B1:D3:73\r\na=setup:active\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n' } }

[ibudisteanu]

I see that computers from some networks connect, while other networks can't connect, although I have provided both STUN & TURN ICE servers. Very probably the simple peers library is not trying to use the 2nd ICE server namely my TURN ICE server

params = {
    initiator: initiator,
    trickle: false,
    reconnectTimer: 100,
    iceTransportPolicy: 'relay',
    config: {

        iceServers: [
            {
                urls: "stun:numb.viagenie.ca",
                username: "pasaseh@ether123.net",
                credential: "12345678"
            },
            {
                urls: "turn:numb.viagenie.ca",
                username: "pasaseh@ether123.net",
                credential: "12345678"
            }
        ]
    }
};

Probably the library is not using the TURN server after the STUN connection fallback. Any idea of how to solve this issue?

[t-mullen]

I've only seen this issue when one or both peers are behind a symmetric NAT, so the problem does lie with the connection to the TURN server. Has anyone tried a non-viagenie TURN server so that we can rule out them being misconfigured?

Could you also confirm you are behind a symmetric NAT by running this JSFiddle on both peers? (https://jsfiddle.net/5ftsd5c2/17/)

[ibudisteanu]

Hi @RationalCoding thanks for helping us out. On the network that other peers can connect the script shows "normal nat", while on the computer that can't connect and can't receive any connections shows "symmetric nat". I suspect the TURN server is never used.

[t-mullen]

I'm noticing there are some reports of viagenie servers not properly collecting relay entries on some browsers, which could explain this. I'll try to set up a coturn server this weekend (or if someone has access to one, please message me).

The ice failures without TURN are due to symmetric NATs, there's nothing to do to fix that.

[ibudisteanu]

@RationalCoding maybe this can help you out to figure the problem. I can run this demo https://www.webrtc-experiment.com/text-chat/#4123528045277047 connecting the computers fast and without any problem (normal nat + symmetric nat).

[t-mullen]

@ibudisteanu That demo doesn't seem to work at all. (Content-security errors and the signal server seems down.)

It does use a coturn server, so I'll try that out.

[t-mullen]

Here's what I've found so far:

• The problem only occurs when one peer has a symmetric NAT and the other peer has any kind of NAT (symmetric or not).
• It's not related to the setup of the STUN or TURN servers (unless they are somehow all misconfigured, which is unlikely. Coturn, restund, and viagenie have the same behaviour.)
• Trickle, reconnectTimer and iceTransportPolicy don't affect it.
• Forcing TCP or UDP transports doesn't help.
• Any combination of browsers will throw the error.
• The error occurs on other WebRTC libraries (namely PeerJS and simplewebrtc)

In Chrome logging, the error is this:

[39692:35211:1103/183902.705873:ERROR:sctptransport.cc(789)] SctpTransport->SendQueuedStreamResets(): Failed to send a stream reset for 1 streams: [0x00000009] Bad file descriptor

I haven't been able to find out if Firefox uses a similar error message since I'm not sure where they would log that.

I'll look into this more later.

[ibudisteanu]

@RationalCoding thanks for your time and nice finding. But, how can we solve this problem? I can confirm that I tried setting different values for trickle and iceTransportPolicy and I've got similar effects.

I see that now this demo no longer works, but yesterday it worked ( i have tested it many times... doh' on Unix and Windows). Now the signaling server is down.

This Web App definitely works and it is online https://opentokrtc.com/ and I have tested it right now on this kind of specific network ( Symmetric NAT and normal NAT) and it works, while the Simple Peer library doesn't work on this kind of connections.

Maybe this article helps https://webrtchacks.com/symmetric-nat/

[t-mullen]

@ibudisteanu I don't know a solution yet.

In your website's case, in seems your TURN server isn't working at all. Try this tool with only your TURN server and it'll come up as unreachable. There should be several candidates there.

[ibudisteanu]

@RationalCoding wait, I don't get it. You are just saying that the turn server turn:numb.viagenie.ca is just offline and this the cause of not allowing symmetric NAT? So, it means that the solution is just to choose a different TURN server that actually works (is reachable)?

I see that these are TURN servers (relay shows available)?

stun:stun.l.google.com:19302

{ //quite slow url: 'turn:192.158.29.39:3478?transport=tcp', credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', username: '28224511:1379330808' },

{//quite slow url: 'turn:turn.anyfirewall.com:443?transport=tcp', credential: 'webrtc', username: 'webrtc' }

Did you try them?

[t-mullen]

They both work. turn:numb.viagenie.ca is working fine now, but was unreachable before. It's ok, you don't have two problems.

[ibudisteanu]

I tried the turn:numb.viagenie.ca and it looks unreachable. See the attached photo

I am new to WebRTC. You are just saying that I should change the offline TURN server (turn:numb.viagenie.ca) to one that is reachable and it should work. Right?

[t-mullen]

If your TURN server is going down frequently, that's going to be a problem. I would ask viagenie for support or use a different server.

There's another problem with TURN servers in general, which is what this issue is about.

[ibudisteanu]

I guessed the issue reported is that we can't connect p2p via symmetric NAT using Simple Peer. Because my ICE servers list is using the viagenie for TURN, and their turn servers are not reachable at my end, the Simple Peer tries to connect the symmetric NAT only via the STUN servers (which is impossible). Here are my questions.

Can I use a longer TURN list to include a few more turn servers? Will the library automatically try to establish the p2p connection using all the TURN servers provided in the ICE list in case the first one will fall? Do, I need to do this fallback solution manually, or will the Simple Peer library do this automatically. Thanks

[t-mullen]

You can provide as many STUN or TURN servers as you'd like. If any are down, the fallbacks will be automatically used. STUN will be attempted first unless `iceTransportPolicy:'relay'`` is set.

Again, none of this will work behind a symmetric NAT because of the above issue.

[ibudisteanu]

@RationalCoding I understand now. I found a new WebRTC library & demo that works on symmetric NAT + normal NAT (tested) https://demo.easyrtc.com/demos/demo_data_channel_messaging.html Maybe this demo will help you understand where the problem for Simple Peer because I truly believe it is a problem somewhere either in the Javascript Interface for WebRTC (Simple Peer npm) or the TURN server (less likely).

Definitely, the mentioned demo is using WebRTC and it works in symmetric NAT. They have also source code provided. Cheers

[t-mullen]

@ibudisteanu That demo uses sendDataWS, which is over websockets, not WebRTC. It's not P2P in any sense.

easyrtc.sendDataP2P is what you want.

[ibudisteanu]

Probably, you clicked on my first link, which I have edited since then to this one https://demo.easyrtc.com/demos/demo_data_channel_messaging.html

This demo ( that I've tested) is using easyrtc.sendDataP2P and it works fine on NAT symmetric + normal NAT

[t-mullen]

Interesting, this does indeed work without falling back to websockets. I'll see if the authors can give us any insight.

[t-mullen]

Here's the minimal demo I've been using to reproduce if anyone is interested in helping with this issue. (You can use https://rabb.it to get a symmetric NAT peer).

https://codepen.io/RationalCoding/pen/bYEmjw?editors=0011

[ibudisteanu]

@RationalCoding EasyRTC looks open source https://github.com/priologic/easyrtc

According to this discussion on EasyRTC's GitHub, Eric is pointing out that any TURN server can be used to establish connections for symmetric NAT. This means that the problem is in Simple Peer Library, where the source code handles the communication with TURN servers.

I want to point one more interesting behavior of this issue. After the signals are successfully generated, the error "Ice connection failed." appears in both browsers, almost simultaneously when they want to establish the p2p WebRTC connection. This means, that the connection is established, but it then gets dropped by the library. Probably a step by step debugging in the Simple Peer Library will reveal where the problem is.

[ghost]

Hi all In my case one side is on browser and the other side is on nodejs. I have my own turn-stun server installed which is online. l forced simple-peer to work with only relay mode then it works on symmetric-nat. But in this mode l can not work with unsymmetric-nat. I also think this is problem of simple-peer.

I could not find a solution yet.

[t-mullen]

easyrtc actually throws the "NOVIABLEICE" error when in debug mode. Unfortunately it seems they have the same issue, but they fallback to websockets.

I don't know why TURN isn't able to traverse symmetric NATs, considering that's one of the reasons TURN exists at all.

My only advice is to use a websockets fallback instead (on ice failure). You're going to be relaying data anyhow, and websockets is more reliable. If you need audio/video you may be out of luck for now.

[bparker667]

I have been using simple peer testing out an application I am working on. Everything has been working fine for a few weeks as long as I have a good turn server and credentials. Since yesterday I am getting this ICE connection failure too. Has anyone had any luck resolving this?

[artus]

I've been having a similar issue, even when using the test page on your readme.md. I can start up the pages and initialize the simple-rtc peers, but when I generate an answer signal from the receiving peer and I don't paste it real quick to the initator, I get the message:

ICE failed, add a TURN server and see about:webrtc for more details

Note that I even tested it with a custom STUN and TURN server from numb.viagenie.ca but I get the same results.

[rivertam]

I've been getting this error a lot (like 20-30 times in a row), even when connection seems to succeed. It's mostly just a nuisance for me, but I'd still rather see it go away. I could definitely be doing something wrong, though. Has anyone else experienced this?

[nathansherburn]

To all the silly geese who don't read properly (of which I'm one), make sure you paste the "answer" back into the initiator when running the code from the README.md.

Failing to do this will result in this same error after the timeout.

[artus]

@nathansherburn , no need to be rude. I do exactly that but still get the error if I don't paste it back quick enough.

[nathansherburn]

Sorry @artusvranken! Wasn't meaning to offend :) Was just trying to use a little self deprecating humour.

I spent an hour trying to debug the code before realising I just hadn't read the instructions properly and was annoyed with myself.

I hadn't actually read your message before but I believe the behaviour you're seeing is what's expected. The offer/answer should only be valid for a short period of time.

[AlbertoElias]

So for me it's unclear if this is an issue with TURN servers or with this library? Using the viagenie servers, I was getting the same issues except with Brave Browser. Brave worked fined with Chrome. But Chrome with Chrome or with Firefox, or Firefox with Firefox didn't work. And with Brave it worked even if I was on symmetric nat.

It seems to work with a custom coturn server for now, still testing

[ghost]

Any update @RationalCoding ? Problem still exists. Thanks,

[ghost]

Hi all,

Here is my latest findings. I was using a my own stun/turn server. Normally stun/turn server uses 2 ports (TCP/UDP) BUT When one or both peer is behind a symmetric NAT, turn server opens other ports to communicate with peers.

My problem was firewall which was blocking peer ports so after that Ice connection error occurs. Firewall or unreachable turn server could be the main reason for that error. Could you please confirm that?

[t-mullen]

This error is caused by either the ports needed to establish a connection to the TURN/STUN servers being blocked or the UDP protocol being blocked.

The issue with Chrome not attempting to use any TURN server appears to have been fixed.

Mobile internet providers block UDP traffic and many ports used by TURN.

Excessively slow signalling can also cause this error, as well as using trickle ice and not delivering all ICE candidates.

Ensure you can connect to your STUN/TURN servers with this tool (make sure you receive at least one relay candidate for a TURN server): https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Try appending ?transport=tcp to the TURN config. You can also try configuring your TURN server to use port 443 as many firewalls will treat TCP traffic on this port as opaque SSL traffic. Lastly, you can try using TLS over TCP to encrypt traffic to the TURN server which should prevent any firewall blocking.

Lastly, try disabling firewalls on both your computer and/or router. If this fixes the issue, your firewall configuration is too strict.

If that still doesn't work, pasting a link to a relatively brief and filtered .pcap file is the only way anyone can help you further. https://webrtc.org/testing/wireshark/

Closing as this appears to be exclusively network-based.

[ilDon]

Ensure you can connect to your STUN/TURN servers with this tool (make sure you receive at least one relay candidate for a TURN server): https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ Try opening all ports on your firewall and appending ?transport=tcp to the TURN config. You can also try configuring your TURN server to use port 443 as many firewalls will treat TCP traffic on this port as opaque SSL traffic. Lastly, you can try using TLS over TCP to encrypt traffic to the TURN server which should prevent any firewall blocking.

@RationalCoding thanks! Your directions where very helpful for understanding why I was not able to connect to my mobile. I strongly suggest to add something about this network-related issue to the README, for those with less experience on webrtc it isn't obvious and it makes simple-peer look buggy, while it's an issue entirely dependant on external factors.

[rubender]

I have the same problem, to solve this I've change locally simple-peer.js change this self._pc = new (self._wrtc.RTCPeerConnection)(self.config, self.constraints) to this

let my_config = {
    iceTransportPolicy: 'relay',
    ...self.config,
}
self._pc = new (self._wrtc.RTCPeerConnection)(self.config, self.constraints)

---

problem is in pass only config of servers to RTCPeerConnection

const peer = new SimplePeer({
      iceTransportPolicy: 'relay', // this property will ignore 
      config: {
        iceServers: [...  ]
      }
    });

[MiguelRipoll23]

After this issue affecting me for a whole day I was able to fix this error after some researching.

1. Turn off Windows Firewall.
2. Request video/microphone permission before starting peer connections as Safari requires you to do this to disable ICE candidate restrictions. So even if you don't use user media, you must do this anyways because it means the user trusts your website. -> Source

These are my ICE servers list just in case:

{'url': 'stun:stun.services.mozilla.com', 'urls': 'stun:stun.services.mozilla.com'},
{'url': 'stun:stun.l.google.com:19302', 'urls': 'stun:stun.l.google.com:19302'}

Now my local devices can connect between each other, I don't know if remote ones work yet because I recently started my project.

[artus]

Issues like this really scare away people trying to work with WebRTC. Users should not have to turn off their firewall just to use a service in their browsers.

[rivertam]

@artus Agreed, but there's nothing this repository can do about it.