I see, you emphasize that Jitsi does not support manual port forwarding.
I don't wan't to spread misinformation. Sorry, if my statements could be misunderstood:
Jitsi does not support manual port forwarding.
Yet, I am questioning if direct calls using manually configured port forwarding
is a something entirely impossible.
What you are describing is a technique known as latching or Hosted NAT
Traversal:
http://tools.ietf.org/html/draft-ietf-mmusic-latching
This is something that can be done if and *only* if one of the peers is
guaranteed to have a public IP address. Latching is therefore generally
only supported by servers (and we actually rely on that for SIP NAT
traversal).
Note that latching DOES NOT in any require port mapping.
Why should that be relevant? Does latching conflict with port mapping?
I see it as a tool to enable comunication with a peer behind
a NAT that invites public IPs to its private IP. (Announcing the private IP may be
required only to facilitate lan-only routes in case both clients happen to
sit behind the same router.)
Respect, if you are even the author of the latching document.
I would really like to understand a concrete restriction why it
should p2p communication can't be facilitated using port forwarding
instead of relays. Maybe throug a simple statement like x can not
determine the port of y because of z could be made.
Why would you say the requirement for a public IP can not be met this way?:
* the router has a public IP
* ports manually forwarded to the same ports on the
client behind the NAT
* client determines its public (forwarded) router address with
the help of a STUN server or UPNP (read only)
* the peer INVITES using the public router IP
Why should a latching peer set up like this then not be able to sucessfully
comunicate with a peer, even when that peer happens not to
INVITE to its public IP but a private IP?
>>> That is the best I got, please correct if that conclusion is not
>>> drawn
>> correctly.
>>
>> If your conclusion is that a user agent can automatically discover
>> a working IP address for the remote party whenever it receives a
>> private one
>
> Not whenever (unconditionally), but when ICE has failed and the
> remote side has configured port forwarding properly.
If it were possible for one of the agents to send packets directly to
the other, ICE wouldn't have failed in the first place.
Oh yes, that is a good question! Why would ICE fail when manual port forwarding
is configured?
* Jitsi not using configured ports?
* ICE not trying the configured local ports and STUN determined IP?
...?
Note that an incoming INVITE comes from the IP address of the signalling
server. So a callee has no way of determining what IP address you are
using based on that alone.
For direct calls it is needed to receive incoming RTP packages to get
the peers public address (thus the port forwarding to allow that).
STUN, VIA messages (sip server/peer dependent), or UPNP (read only) can
be used to let a peer know its own public address, and use it in INVITES.
I am just ... totally lost 
Yeah, me too 
... We make it clear that port forwarding
is not helping. You claim that some users would still do port forwarding
and then be confused because it does not work?
Hm, not exactly. I read port forwarding is not helping, and the responses to users
sound as if it is impossible at all (not just unsupported).
At the same time many SIP devices, e.g. the SPAs, work quite well behind
NAT routers with port forwarding. In fact port forwarding seems a pretty standard
measure in p2p comunication and SIP http://kb.smartvox.co.uk/voip-sip/sip-devices-nat/
That is probaly the reason for why so many ask about it for jitsi.
To me the fact that things don't work when someone told me they wouldn't
work actually sounds pretty consistent ...
It would sound consistent to me as well, if only there would be no successful port
forwarding practice elsewhere.
> I can't think of a reason why the same protocol should not work with
> fixed jitsi ports and manual port forwarding configured in the
> router.
I answered this exact question in my previous mail:
> Correct. We have ICE support for XMPP and we also explicitly support
> UPnP so *Jitsi* can automatically allocate public ports on a local
> NAT. Contrary to manual port forwarding, this way it would know what
> they actually are and would include them among the other ICE
> candidates.
What specifically do you consider as unknown when the user manually
configures explicit ports for jitsi to bind to and ports on the router to forward?
When you forward ports manually, Jitsi has no idea that you have done that.
Couldn't ICE just try the local port and the public IP, or a forwarded_ports configuration
option provide that information?
Cheers,
Chris
PS: I still could not reproduce the ongoing audio after the call ended.