this text. Unfortunately, I don't believe it conveys accurate
information and I personally don't see how it is helpful.
Emil, thank you for your feedback (see below).
Could you mention the other points that you think need correction, if any?
(version in http://lists.jitsi.org/pipermail/users/2014-February/006542.html)
Of course, for you it won't be that helpful ;), since you know pretty
well how jitss works. It tries to explain things to admins and users
that want to understand or are in need to do some administration.
>> 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.
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.
Exactly, so the address may be non functional.
> 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
Ah thanks for explaining, so if a STUN determined IP is always tried as well,
the error I got should have nothing to do with false UPNP lookup result.
>> 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
Ah, ok... If that is the case, could you please explain why port forwarding
I see jitsi tries hard to work without requireng configuration, but when the
circumstances don't allow that jits works out of the box (e.g. depending on
how the router maps frequent port or ipv6 prefix/suffix changes) why
can't the standard port forwarding procedure help?
In the case above, allowing dynamic UPNP configuration of portforwarding
makes the ICE error go away, but in evironments where that is a no-go, it
would be good if configuring a static port forwarding would help.