I had also looked at jitsi, and faced the ICE failure, and
many threads about it.
With the help of the kind users and devs on this list I
compiled the following (now updated) FAQ proposal.
= Why do I see ICE failed errors when trying to make calls? =
This error message should rather say something like:
This call could not connect with the current setup (ICE failed).
The tests determined that you are located behind a NAT router of the
xxx type. The simple solution is to use and depend on a provider that
relays your communication. Otherwise, you would have to configure a
"TURN" or "jingle" relay node.
NOTE: Currently, Jitsi does officially NOT support to use only specific
ports, and work with manually configured port forwardings that are
configured on the router. (The usual cure for NAT issues.)
Jitsi tries to connect calls between you and other users seamlessly,
without requiring further configuration. However, depending on the
infrastrucure of your local network (router/modem) and your XMPP
(jabber) or SIP (VoIP) provider, you may still find yourself in a
situation where "ICE failed" and you need to adapt your configuration.
== What can I do for Jitsi ==
Jitsi does NOT support configuring manual port forwarding on the router
to solve "ICE failed" NAT issues. It depends on relay servers to
circumvent NAT issues. If your XMPP (jabber) or SIP (VoIP) provider
does not offer relaying services, you need to change your provider or
configure an an own relay node. If you are looking for services
that provide relays, you can try our jit.si[LINK] or ippi[LINK].
The supported relay types are TURN[LINK] or jingle[LINK].
If you see ICE failed errors, even with relay servers available:
* Make sure that both you and your partner have unhindered outgoing
UDP access to the Internet or at least to your VoIP service provider's
relay nodes. You can test this by...[LINK]
* There is a bug that occurs with multiple network cards in windows
NOTE: Only if you are sure about the securty consequences for your
network, and if your router supports it, you may enable UPNP
configuration in your router. Jitsi can then automatically set up the
required port forwarding through UPNP, but allowing UPNP configuration
will also allow malicious programs to open ports on the router.
== Background (TL;DR) ==
Programs running on devices with different IP addresses use specific
port numbers when they communicate over a network, and the personal
devices may have private (non-routable) IP addresses assigned to their
local lan and wlan interfaces.
A router has at least one public IP address on its external interface
and may have a private address on its internal network interface. It may
then forward data packages between the internal and external network
doing network address translation (NAT). NATing requires to map port
numbers on the external interface to the internal IP and port number
of the program running on an internal device that wants to communicate
with the outside world.
A decent firewalling router (that protects internal computers from
unrelated access from outside) will only allow incoming
packages, and forward them to a program on an internal network device
that, that come back as responses to connections that originated from
Problems arise when protocols transmit ports and IPs within packages,
in addition to the packets sender and target ports and IPs that get
translated by the NAT routers automatically.
Either, at least one peer will have to take full connection
responsibility and attempt to determine its public port and IP,
transmit those in the packages send to public IP addresses, as well as
try to connect back to the sender port and IP of received packages,
instead of the tranmitted address, if they don't match.
Or, there will remain a dependency on centralized infrastructure.
To implement full connection responsibility of a peer for all kind of
NAT routers, the software run at a peer can not just rely on configuring
port forwarding in the NAT router through UPNP, not all routers support
this, and allowing this in routers that support it can be considered a
The alternative for the software is to suggest the forwarding settings
for the router (with the ports currently used by the software) to be
configured by the user (or network admin), if no relay is found.
And to make the used ports really easy to configure in the software, to
solve conflicts if the ports may already be forwarded in the router for
Centralized infrastructure can help in establishing direct
connections between two peer devices that are both behind different NAT
routers, and in fact often tries supports this to reduce the
resources that are required to provide the central service. The
principle here is to let both peers connect to each other, opening the
NATs on the routers in both ways (e.g. hole punching, or "ICE" NAT
traversal methods [LINK]). But there will allways be routers with NAT
or packet filtering setups to prevent this.
For example, central infrastructure can not help in establishing direct
connections between peers, where the external router port on which a
program running on an internal device is reachable (for the responses
from outside) depends on the IP (destination) to which the program has
connected. In this case, because they won't listen on the same ports
used to connect to the coordinating server, to connect to each other.
This means central the infrastructure appoach will always require
relays for connections with devices behind a good number of NAT
Thus, to enable reliable connections from behind NAT routers in all
cases, peers will either need an external relay server (own or from
provider), or set up port forwarding in the router.