Re: [GnomeMeeting-list] Outgoing calls from behind the NAT

[Damien Sandras <dsandras seconix com>]

Le mercredi 22 février 2006 à 15:28 +0100, Jan Kasprzak a écrit :
> Damien Sandras wrote:
> : It is due to the way the Linux NAT is working, I don't want to enter
> : into complex explanations, so I will go straight to the fact: have you
> : increased the UDP binding timeout as described in the FAQ?
> 
> 	No (the question in FAQ is something about unregistering
> after 30 seconds, which apparently is not my problem). Nevertheless,
> I have changed the timeout to 3600 seconds now, and the the problem
> is still here (after restarting ekiga on both sides). Call to 500 ekiga net
> works, call to another ekiga with public IP address does not.
> 

If I was you I would check the bindings.

STUN is used (very basically) to determine the ports that will be used
by your router as source ports for outgoing packets. 
Knowing that, he can put that port in the SIP PDU and the remote
softphone can answer back on that port.

The problem with the Linux NAT is that it is symmetric NAT, so basically
it should not work. Symmetric NAT means that the port that will be used
for outgoing packets on the NAT router is different following the IP
address that you are communicating with. So STUN will tell that port X
is used, but port Y will be used because the IP address of the STUN
server is not the IP address of the softphone you are communicating
with.

However, the Linux NAT also uses a technic called "port overloading",
meaning that the same port on the router can be used for different
remote IP addresses, despite it is symmetric NAT. But it is not
predictable.

That means that:
- Ekiga will query the STUN server to know what port will be used for
RTP, the STUN server tries several ports and returns one because it
thinks that this port will be used for all communications to the given
remote IP with the given source port on the internal machine. However,
that is only true if that port is not already used (it is the case in
most of the cases).
- I think that the STUN server reported one port, but that this port was
already used for another communication of your internal machine, so a
different port was used when calling than the one when communicating
with the STUN server.

My suggestion: reboot the router to purge the bindings. Increase that
binding timeout, and call.

If you want a 100% safe solution for a Linux NAT, use sipproxd, but it
has bugs with video. However, it also allows calling between users who
are located behind the same NAT.

-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net