[jitsi-users] ICE failed FAQ update (was: Jitsi error: "call ended by remote side - Reason failed-application... (ICE failed)")


#1

This is not an official jitsi.org statement, but kind user feedback, improvements welcome:

-Chris

= 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
http://lists.jitsi.org/pipermail/users/2014-February/006541.html.

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
that device.

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
security hole.
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
other purposes.

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
routers.

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.


#2

Hello,

I am interested to know about Jitsi meet conferencing features that are
under development or planned, and I haven't found any roadmap on
jitsi.org nor github.

Are any of these considered for near-future development or under
development?:

- 'raise hand' status (or similar)
- whiteboard (allowing drawing and similar)
- on-screen timer (clock)
- polls

And... is the text editor on meet.jit.si loading fine for others? In my
case it shows loading progress but never loads. (Jitsi 2.5.5204 on
Ubuntu 14.10).

thanks

karel


#3

This is not an official jitsi.org statement, but kind user feedback, improvements welcome:

Who is this text meant for? I am asking because this text is nowhere near a shape where we'd be happy with it to go on a Jitsi approved FAQ. I would have assumed it is for your personal information if it weren't for the fixation with port forwarding. Let's proceed under the benefit of doubt though ...

Some more notes below.

-Chris

= Why do I see �ICE failed� errors when trying to make calls? =

Jitsi only supports

*currently*

to connect calls between you and other users reliably
(and without requiring further configuration), under these conditions:

XMPP (jabber): IPv6, UPnP, or relay server

This is not accurate. It would also work if users are behind NATs that perform endpoint independent mapping (the majority of NATs available today).

It would also obviously work with IPv4 public addresses.

SIP (VoIP): relay server

I think the use of a "relay server" in both of these is ambiguous. Jitsi will connect two users through SIP if the SIP service provides "Hosted NAT traversal" also known as "Latching".

Jitsi would not currently work if you can only connect to the internet through TCP. (Jitsi Meet would).

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.

Well not really. Users can do little about their configuration in such cases. It is something that would need to be resolved by their VoIP and/or Internet service providers.

The �ICE failed� error message could rather provide information like:

No. The "ICE failed" error message is just an error message. It is not a tutorial so it cannot popup that much text every time it happens. It can however convey an extra clue.

   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.

I don't know what an XXX type would be. I am not aware of an exhaustive NAT classification that would allow to slap an accurate type label above.

   The simple solution is to use and depend on a provider that
   relays your communication.

That also provides a relay for your communication when you need it.

Otherwise, you would have to configure a
   "TURN" or "jingle" relay node.

This kind of makes it sound as if the relay in the previous sentence is different from TURN or Jingle Relay Nodes.

   NOTE: Currently, Jitsi does officially NOT support to use only specific
   ports

That's wrong. Jitsi uses ports 5000 to 6000 for media and this is configurable.

   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).

This is misleading. As it presents UPnP as somehow more of a threat than static port forwarding. We've been through that.

== 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.

This is not very accurate either. You keep insisting on forwarding ports and I keep telling you not to. Forwarding ports is confusing. People are not able to do that in general and it is a use case we do not wish to care for.

It depends on relay servers to
circumvent NAT issues.

Wrong. First it depends on relay servers "as a last resort". Second you make this sound as if relying on manual port forward will eliminate the need for relays. This is very misleading. You can already go ahead and play with your NAT and forward the 5000 to 6000 port if you wish but this will cause issues for other devices and it would also mislead users into thinking that this is a mandatory step. Port forwarding is a crappy thing to advice and we will never do so. Please stop posting on the subject of port forwarding.

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
http://lists.jitsi.org/pipermail/users/2014-February/006541.html.

That part is actually mostly ok.

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.

UPnP would still not work in the presence of cascaded NATs

Reliable direct calls without relay servers or UPNP should be
possible, when jitsi supports user configurable ports (to be forwarded
on router),

There you go again. Jitsi already supports use of configurable ports. It's port forwarding itself that is:

* prohibitive (only some people would have that feature available on their home gw and only some of them would have the right to access it)
* error prone (could hurt other devices on the same network that are not the target of the forward or it would in explicable stop working when your device changes its IP for some reason)
* unreliable (won't work behind cascaded NATs)
* confusing (what's a port exactly? and wait, are you saying I need to know all that shit in order to use Jitsi? oh man, this sucks, I'll just use Skype)

Advising port forwarding is harmful!

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.

I have no idea what the above sentence means.

== 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.

This tries too hard to oversimplify things and it ends up being wrong.

A router

You really mean a NAT here. A router is a layer 3 device that routes IP packets.

has at least one public IP address on its external interface
and may have a private address on its internal network interface.

Why may? Are you saying that it may also NOT have an internal network interface?

It may
then forward data packages

I don't know what a package is. Maybe you mean a packet.

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,

packets

and forward them to a program on an internal network device
that, that come back as responses to connections that originated from
that device.

Problems arise when protocols transmit ports and IPs within packages,

packets

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.

Oversimplification again.

Also, centralised architecture is necessary for many other things than just being able to advertise a relay.

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
security hole.
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.

No. The alternative is for the application to try and do its best with a direct connection (which should work in 60% yo 92% of the use cases) and then relay.

Port forwarding requires skills and gw features that make the solution marginally useful.

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
other purposes.

The ports are 5000 to 6000 in Jitsi and you can change them if need be. Have fun.

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

Always? No this is very misleading. A relay needs to be available for it to be used *on occasion*.

good number of NAT
routers.

Where does that "good number" come from and what is it exactly?

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.

Again, port forwarding is much more prohibitive and unreliable than relying on relaying so this is misleading at best.

I don't find this to be a productive discussion. And I'd really appreciate if you'd just cut it.

I find your insistance on port forwarding to be harmful so please don't post about this again. There must be tons of other applications, forums and list that would be more suitable.

Thank you.
Emil

···

On 24.04.14, 09:44, ca2013@arcor.de wrote:

--
https://jitsi.org


#4

* There is a bug that occurs with multiple network cards in windows
http://lists.jitsi.org/pipermail/users/2014-February/006541.html.

FYI: This should be fixed in Java 8, and so would be Jitsi once we ship with
JRE 8.
https://bugs.openjdk.java.net/browse/JDK-6458027

That part is actually mostly ok.

Ingo


#5

Hello,

I am interested to know about Jitsi meet conferencing features that are
under development or planned, and I haven't found any roadmap on
jitsi.org nor github.

Yes, there's none at this point.

Are any of these considered for near-future development or under
development?:

- 'raise hand' status (or similar)

Not really. People can just send an instant message and we'd like to
avoid cluttering the interface with things that would only be of use
in a minority of cases.

- whiteboard (allowing drawing and similar)

We haven't thought about this so far but there are options that allow
doing this through a web interface. It will be just a matter of
integrating it. No specific plans so far but I assume it may still end
up being contributed at some point.

- on-screen timer (clock)

That's an interesting one. We'd like to have that!

- polls

We are thinking of adding a +1 (or like) option for instant messages.
Can't give you an ETA though.

And... is the text editor on meet.jit.si loading fine for others?

You mean etherpad? Yes that sometimes happens but we don't know why.
Often times restarting chrome helps. You can also try switching from
Chromium to Chrome or vice versa.

Emil

···

On Fri, Apr 25, 2014 at 2:35 PM, Karel Novotny <novotny.karel@gmail.com> wrote:

In my
case it shows loading progress but never loads. (Jitsi 2.5.5204 on
Ubuntu 14.10).

--
https://jitsi.org


#6

Hi Emil, thanks for response...

Are any of these considered for near-future development or under
development?:

- 'raise hand' status (or similar)
Not really. People can just send an instant message and we'd like to
avoid cluttering the interface with things that would only be of use
in a minority of cases.

Quite different from using a chat window - I find a sound signal (beep)
associated with "hand rise" very useful as it is very common that in a
multi-person meeting the talker can not keep track of the chat flow
while talking.

But your point about minority taken. Can be.

[...]

We are thinking of adding a +1 (or like) option for instant messages.
Can't give you an ETA though.

great. Hope the idea will get traction.

And... is the text editor on meet.jit.si loading fine for others?

You mean etherpad? Yes that sometimes happens but we don't know why.
Often times restarting chrome helps. You can also try switching from
Chromium to Chrome or vice versa.

It is always the case for me. Stuck loading. Will try swapping as you
suggest. If there is any log I can send which could shed light on this,
let me know.

thanks

karel

···

On 26.4.2014 19:45, Emil Ivov wrote:

Emil

In my
case it shows loading progress but never loads. (Jitsi 2.5.5204 on
Ubuntu 14.10).