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 [EMAIL > PROTECTED] > 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:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] _______________________________________________ GnomeMeeting-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
