This is not an official jitsi.org statement, but kind user feedback, improvements welcome:
= Why do I see ICE failed errors when trying to make calls? =
Jitsi only supports to connect calls between you and other users reliably
(and without requiring further configuration), under these conditions:
XMPP (jabber): IPv6, UPnP, or relay server
SIP (VoIP): relay server
Depending on the network infrastrucure beteen the endpoints (routers/modems)
and your XMPP (jabber) or SIP (VoIP) provider, you will encounter situations
where "ICE failed" and you need to adapt your configuration.
The ICE failed error message could rather provide information like:
This call could not be connected with the current setup (ICE failed).
The tests determined that (or most probably) you are located behind a
NAT router of the xxx type and no relay servers are available.
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 to work with manually configured port forwarding settings
in your router. (The usual cure for NAT issues.) And enabling automatic
UPNP port forwarding configuration in your router, would allow any
device or malware in your network to open ports (not just jitsi).
== What can I do for Jitsi ==
Jitsi does currently NOT support working with 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 could 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
on the router will also allow malicious programs to open and listen
on server ports.
Reliable direct calls without relay servers or UPNP should be
possible, when jitsi supports user configurable ports (to be forwarded
on router), INVITE non-lan IPs to the own public (STUN determined) IP
and ports, and to respond to the public sender IP if a lan IP in the
packet does not work (latching). Hopefully somebody can implement this.
will implement them some day.
== 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.