-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I do know that there is this wonderful feature called ICE but
apparently it does not make use of any kind of dnat
How is one supposed to actually use DNAT?
Probe for my external IP using STUN and try connecting to that IP from
outside (that works, I have tested that a lot of times using netcat,
you can reach my computer on every port when you try to contact my
ICE does that. (Note that use of STUN outside ICE is not recommended).
If you are forwarding ports, then you've taken it up upon yourself
to make things work and in that case it's up to you to make sure
that they are.
You need to make sure that these ports are also properly allocated when connections originate from the inside. Some NATs would keep them for incoming connections only. Of course, this would require traffic analysis during Jitsi call setup.
Have you tried to look at the traffic?
Which traffic exactly?
The STUN requests and the STUN connectivity checks that are part of ICE.
I have looked at the traffic of an ongoing call
and it uses a relay, I am unable to view the signalling traffic as the
connection to the server is encrypted
Ingo has already explained that this is part of our pcap-s. However, most of the trouble shooting should focus on STUN and that's plain UDP.
so whenever I call somebody (or somebody calls me) it either
fails or makes use of a media relay which is complete nonsense as
i am perfectly reachable on ALL of the ports in UDP and TCP.
This drives me mad, hope somebody can help me with it.
Keep in mind that ICE isn't magic. It simply takes your addresses,
sends them to your peer and then tries all of them. If ICE switches
to use of a relay, this means that the attempts to use any other
addresses have failed.
Does it Include my public IP address?
It includes any address that it can find. In addition to the address that it discovers via STUN it would also try UPnP and IPv6 and Jingle Nodes and TURN.
If it does I have no idea why it
would not work.
That's where analysing traffic would be important. Maybe your NAT does not behave exactly like you want it to. Or maybe it just applies some level of endpoint dependent filtering on inbound connections, which would not be a problem in normal situations. However if the remote party is behind a NAT with endpoint dependent mapping (a.k.a. symmetric) then it could cause traffic to go through a relay.
Hope this helps,
On 01.06.13, 16:34, Yannik Völker wrote:
On 01.06.2013 07:03, Emil Ivov wrote:
On Sat, Jun 1, 2013 at 3:50 AM, Yannik Völker <email@example.com> >> wrote:
It would be really nice to have a pidgin-like xmpp-monitor to make
debugging such issues easier.
P.S. I assume all this on XMPP? We don't currently have ICE with
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
-----END PGP SIGNATURE-----
users mailing list
Unsubscribe instructions and other list options: