[jitsi-users] lan behind multiple routers: responding to calls gives "ICE failed" errors


#1

Hi there,

calls work fine (saw the error only occasionally) when the computer is connected to
a lan with only one router that has a public IP on the outside.

But if one side is connected to a router that has a private lan IP (router behind another router),
calls always end with an error the moment that the called party tries to pick it up with (ICE failed).

The issue https://java.net/jira/browse/JITSI-934 made me speculate it could be related,
to UPnP and jitsi failing ICE or using the wrong UPnP settings from the nested router
(and not falling back to STUN or something). Could that be the case?
Disabling UPnP for the Accounts did not seem to make a difference, though.

I am running out of my newbie ideas, how to identify and solve the issue?

Cheers,
Chris


#2

13 feb 2014 kl. 19:54 skrev ca2013@arcor.de:

But if one side is connected to a router that has a private lan IP (router behind another router),
calls always end with an error the moment that the called party tries to pick it up with (ICE failed).

I have this problem too. In a local setup I have been unable to test audio and video calls. Is there a specific configuration to enable audio and video on a local lan when using openfire?

/Peter


#3

Hey Caleb,

I have just added the following FAQ entry:
https://jitsi.org/faq/ice-failed

Cascading NATs do not inherently imply this but my speculation is that
one of them performs endpoint dependent mapping and that your service
provider does not provide relaying capabilities.

Hope this helps,
Emil

···

On Thu, Feb 13, 2014 at 7:54 PM, <ca2013@arcor.de> wrote:

Hi there,

calls work fine (saw the error only occasionally) when the computer is connected to
a lan with only one router that has a public IP on the outside.

But if one side is connected to a router that has a private lan IP (router behind another router),
calls always end with an error the moment that the called party tries to pick it up with (ICE failed).

The issue https://java.net/jira/browse/JITSI-934 made me speculate it could be related,
to UPnP and jitsi failing ICE or using the wrong UPnP settings from the nested router
(and not falling back to STUN or something). Could that be the case?
Disabling UPnP for the Accounts did not seem to make a difference, though.

I am running out of my newbie ideas, how to identify and solve the issue?

Cheers,
Chris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#4

Hello Emil!

Cascading NATs do not inherently imply this but my speculation is that
one of them performs endpoint dependent mapping and that your service
provider does not provide relaying capabilities.

Hope this helps

Yes, thank you. I also found the loggins settings there.
I'll see if they can tell me what is going wrong.


#5

Hello all,

thanks for the guidance, Emil!

I have just added the following FAQ entry:
https://jitsi.org/faq/ice-failed

And from my findings I have now compiled some additional text you are welcome to
add to the FAQ after proofreading if you like:

= Background =

Usually, the lan and wlan interfaces of personal devices have private
IP address assigned, and programs running on the computer use specific
port numbers when they communicate over a network port.

A router has a public IP address on its external interface and a private
address on its internal interface. It may forward data packages between
the internal and external network doing network address translation
(NAT). The NAT requires to map port numbers from on the external
interface to the internal IP and port number of the internal devices.

A decent firewalling router (that protects internal computers from
unrelated access from outside) will only allow forwarding incoming
packages that come back as responses to connections made from a program
on an internal computer. There are still routers that allow
incoming connections from anywhere after a program on an
internal computer has sent a package to some external destination.

Directly transferring data between computers that are behind
different NAT routers requires some coordination by an external server,
to let both programs connect to each other and initiate the NAT in both
routers. (Except, when the IPs and external ports of each other are
known and don't change.) But this should be taken care of by jitsi's ICE
features.

A problem should only arise, if the external port on which a program
running on an internal computer is reachable (for the responses from
outside) depends on the IP to which the program has connected. In this
case, it is not possible to coordinate both programs to connect to each
other directly, since they won't use 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. This set up may be done by the program running on the
internal computer itself, if the router allows UPNP configuration, or by
configuring the program to use only specific ports and manually setting
up port forwarding to these ports on the router. Allowing routers to be
configured by arbitrary programs through UPNP is not a good idea in
general, and thus disabled on decent routers.

= What to do =

Users that do not want to adjust the router configuration, nor set up
their own relay server (e.g. TURN or jingle node), nor use
another router or install specialized gateway features, will just have
to rely on (switch to) services that provide relay
servers to be able to connect to arbitrary destinations.

But to avoid the requirement to transfer over relay servers
with problematic routers, you may configure jitsi to use only specific
ports, and manually configure the router to do specific port
forwarding to them. (If the router supports it, automatic configuration
by UPNP may be allowed in the router, and jitsi will take care of
setting this up, but this 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


#6

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


#7

Hey there,

Hello all,

thanks for the guidance, Emil!

I have just added the following FAQ entry:
https://jitsi.org/faq/ice-failed

And from my findings I have now compiled some additional text you are welcome to
add to the FAQ after proofreading if you like:

= Background =

Usually, the lan and wlan interfaces of personal devices have private
IP address assigned, and programs running on the computer use specific
port numbers when they communicate over a network port.

A router has a public IP address on its external interface and a private
address on its internal interface. It may forward data packages between
the internal and external network doing network address translation
(NAT). The NAT requires to map port numbers from on the external
interface to the internal IP and port number of the internal devices.

A decent firewalling router (that protects internal computers from
unrelated access from outside) will only allow forwarding incoming
packages that come back as responses to connections made from a program
on an internal computer. There are still routers that allow
incoming connections from anywhere after a program on an
internal computer has sent a package to some external destination.

Directly transferring data between computers that are behind
different NAT routers requires some coordination by an external server,
to let both programs connect to each other and initiate the NAT in both
routers. (Except, when the IPs and external ports of each other are
known and don't change.) But this should be taken care of by jitsi's ICE
features.

A problem should only arise, if the external port on which a program
running on an internal computer is reachable (for the responses from
outside) depends on the IP to which the program has connected. In this
case, it is not possible to coordinate both programs to connect to each
other directly, since they won't use 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. This set up may be done by the program running on the
internal computer itself, if the router allows UPNP configuration, or by
configuring the program to use only specific ports and manually setting
up port forwarding to these ports on the router. Allowing routers to be
configured by arbitrary programs through UPNP is not a good idea in
general, and thus disabled on decent routers.

= What to do =

Users that do not want to adjust the router configuration, nor set up
their own relay server (e.g. TURN or jingle node), nor use
another router or install specialized gateway features, will just have
to rely on (switch to) services that provide relay
servers to be able to connect to arbitrary destinations.

But to avoid the requirement to transfer over relay servers
with problematic routers, you may configure jitsi to use only specific
ports, and manually configure the router to do specific port
forwarding to them. (If the router supports it, automatic configuration
by UPNP may be allowed in the router, and jitsi will take care of
setting this up, but this will also allow malicious programs to open
ports on the router.)

I appreciate the effort and thank you for taking the time to write
this text. Unfortunately, I don't believe it conveys accurate
information and I personally don't see how it is helpful.

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.

While possible in theory, I have never come across a home router that,
upon receipt of an UPnP query, would initiate a second UPnP query to
any routers that precede it.

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.

I don't quite understand this sentence. Whatever addresses are
returned from UPnP, they will be tried with ICE, together with
anything else. If they work, they might get used. If they don't, they
won't.

but my speculation is
that one of them performs endpoint dependent mapping

Is there some way I can find this out? (from the logs?)

You'd have to launch traces on your NAT devies.

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?

The very reason I created that FAQ entry is because mapping ports WILL
NOT help. I don't know if that's what you are planning on doing but I
thought I'd mention it just in case.

Here are all relevant properties:

net.java.sip.communicator.service.protocol.MAX_MEDIA_PORT_NUMBER
net.java.sip.communicator.service.protocol.MIN_MEDIA_PORT_NUMBER
net.java.sip.communicator.service.protocol.MIN_VIDEO_PORT_NUMBER
net.java.sip.communicator.service.protocol.MAX_VIDEO_PORT_NUMBER
net.java.sip.communicator.service.protocol.MIN_AUDIO_PORT_NUMBER
net.java.sip.communicator.service.protocol.MAX_AUDIO_PORT_NUMBER

Cheers,
Emil

···

On Fri, Feb 14, 2014 at 6:33 PM, <ca2013@arcor.de> wrote:

--
https://jitsi.org