Hi,
here is an improved version of the FAQ text. I merged in the text from the current FAQ entry and mentioned the multi interface issue.
Please add some info about specifying the ports for jitsi to use.
(I wrote [LINK] where the current text provides links.)
I have just added the following FAQ entry:
https://jitsi.org/faq/ice-failed
Why do I see ICE failed errors when trying to make calls.
In many situations jitsi will be able to setup calls between you and other users seamlessly, but depending on your XMPP (jabber) or SIP (VoIP) provider's infrastructure, and your local router configuration, you may find yourself in a situation where "ICE failed".
= Background (TL;DR)=
Programs running on devices use specific port numbers when they communicate over a network, and personal devices often have private IP addresses assigned to their lan and wlan interfaces.
A router often has a public IP address on its external interface and a private address on its internal interface. It may then forward data packages between the internal and external network doing network address translation (NAT). NATing requires to map port numbers from the external interface to the internal IP and port number of the program running on an internal device.
A decent firewalling router (that protects internal computers from unrelated access from outside) will only forward incoming packages that come back as responses to connections made from a program on an internal computer.
Directly transferring data between two computers that are both behind different NAT routers thus requires some coordination by an external server, to let both programs connect to each other and initiate the NAT in both routers. (If each others IPs and external port number are not known.) To solve this requirement, Jitsi implements a number of NAT traversal methods as described here[LINK].
Nevertheless, a problem remains, if the external port on which a program running on an internal computer is reachable (for the responses from outside) depends on the IP (destination) to which the program has connected. In this case, it is not possible to coordinate both programs to connect to each other directly, because they won't listen on the same ports used to connect to the coordinating server, to connect to each other.
Transfers between computers behind such problematic NAT routers (where the external ports depends on the destination), will only work through a relay server, or by setting up port forwarding for a specific port.
= What to do =
First, 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]
If you still see ICE failed errors, you are behind a router with problematic network address translation (NAT), or hit by a bug that occurs with multiple network cards in windows http://lists.jitsi.org/pipermail/users/2014-February/006541.html.
If it is not possible, or you do not want to, adjust the router configuration, nor set up an own relay server (e.g. TURN[LINK] or jingle node[LINK]), nor install a different router or specialized gateway features, you will just have to switch to and rely on a XMPP or SIP provider that keeps relay servers in place that jitsi can use to connect with arbitrary destinations. If you are looking for services that support these, you can try our jit.si[LINK] or ippi[LINK].
If you don't want to change your XMPP or SIP provider, or don't want to depend on third party relay servers, you could configure jitsi to use specific
ports, and manually configure the router to do forward some of its public ports to them. The forwarded ports will override the problematic NAT's port allocation. (If the router supports UPNP, you may even allow the configuration of the port forwarding through UPNP in the router, and jitsi can automatically set this up through UPNP, but allowing UPNP configuration will also allow malicious programs to open ports on the router.)
Cascading NATs do not inherently imply this
Yes.
With UPNP however, I think the "public" IP that may be determined by
UPNP would actually be a IP from the outer LAN. So jitsi may
have to make sure not to use, and not to fail when UPNP discovery
returns such IPs, instead verfy / fall back / go on to use say a STUN
determined external IP.
but my speculation is
that one of them performs endpoint dependent mapping
Is there some way I can find this out? (from the logs?)
and that your
service provider does not provide relaying capabilities.
Yes, that is very likely so, as it is just a jabber service, and
should remain so. Could you please post the configuration parameters to
bind or control the ports used by jitsi, if possible?
Cheers,
Chris
