[jitsi-users] ICE FAQ update (was: lan behind multiple routers: responding to calls gives "ICE failed" errors)

Hi, would be nice if there could be a chance to update the FAQ.

Sat, 15 Feb 2014 14:29:38 +0100 (CET)



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

= 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

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

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


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?


users mailing list
Unsubscribe instructions and other list options: