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

[NIV VAIZER <nivv cs bgu ac il>]

Thanks Damien,
I didnt know that.
interesting.

Niv
Damien Sandras wrote:

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