0

I am writing a WebRTC application and although everything works fine inside my LAN. However, I have an ICE Failed error when peers are on different networks.

My STUN server returns public IP candidates so I assume it is set up correctly. The problem is that the candidate IPs are not "paired correctly". The browser always tries to connect one public IP with one private IP so the connection fails (See Candidate Pairs).

What could be the problem here? the signaling server or the rtcpeerconnection configuration?

Antonin M.
  • 1,744
  • 1
  • 18
  • 29
Nikos P
  • 1
  • 1
  • 2
    I think that it does not work because something blocks your P2P flow in the network (i.e. Firewall, symmetric NAT, etc.). Could you try with a TURN server ? – Antonin M. Dec 09 '15 at 12:52

1 Answers1

1

Using only local host and server-reflexive candidate you can only connect if your NAT allows incoming packets from other peer, usually NAT doesn't allow incoming packets from a source which is unknown to the NAT. You can do a NAT discovery outside of your WebRTC implementation following the RFC-3489 (obsolete though, but still helpful) or just create NAT binding without knowing the NAT type which will work if you are behind port-restricted cone or full-cone NAT types. The easy solution to connect using WebRTC would be using a TURN server to have Relay candidate if you don't want to do NAT discovery and apply some intelligence to traverse the NAT.

Palash Borhan Uddin
  • 374
  • 3
  • 12
  • Somewhat true. The whole point of STUN is to identify your server-reflexive candidate such that the ICE algorithm in WebRTC can perform the UDP hole punching step with compatible NATs. As long as you (or the other node) aren't behind a symmetric NAT or restrictive firewall, STUN has a high (but not perfect) rate of success. – selbie Dec 12 '15 at 07:37