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

[Damien Sandras <dsandras seconix com>]

Le mercredi 22 février 2006 à 23:37 +0100, Jan Kasprzak a écrit :
> Damien Sandras wrote:
> : If I was you I would check the bindings.
> : 
> 	I am sorry I don't understand - which bindings?

The UDP bindings on your NAT router. Ie, the table in /proc that tells
what ports are open and for which internal machine/external machine.

> 
> : 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.
> 
> 	Yes, this was my idea about how Linux NAT work - so I could not
> imagine how the STUN can work, when the SIP phone communicates with
> different IP than the STUN client.
> 
> : 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.
> : 
> 	I will try this. However, from your explanation it seems that
> even if it works, it works by a pure luck, and almost any UDP communication
> can disturb this.

I wouldn't say "pure luck", but it is not 100% safe indeed. It won't be
able to allocate the same port on the router than on the softphone if
that port is already allocated for a communication from your internal
machine to the same external machine. So I would say it is pretty rare.

The port allocated by the Linux NAT router depends on 5 parameters:
- remote IP
- remote port
- internal IP 
- internal port
- the protocol

So if your internal machine requests port 5000, port 5000 will be
allocated except if it is already allocated for the same 5 parameters.

Notice that "remote IP" in your case is the STUN server IP address or
the remote softphone, and they differ, so the port allocated could be
different, if another binding already exists, which is extremely
unlikely.


> 
> : If you want a 100% safe solution for a Linux NAT, use sipproxd, but it
> : has bugs with video.
> 
> 	I do not use video now, so siproxd is fine for me (it would allow
> me to run ekiga even on the NAT gateway _and_ on some inside hosts).
> 

Indeed.

> 	Are there any hints about configuring siproxd for ekiga? I have the
> following in /etc/siproxd.conf, but I cannot establish a call from behind
> the NAT - the remote (public IP) ekiga can see and accept the incoming
> call, but the ekiga behind the NAT signalls that it "could not connect
> to the remote host". After the second call, the remote ekiga prints
> the following (and no further call can be made).
> 
> (ekiga:14826): Gtk-CRITICAL **: gtk_tree_model_filter_real_unref_node: assertion `elt->ref_count > 0' failed
> 
> I use the following uncommented lines in /etc/siproxd.conf:
> 
> if_inbound  = eth1 # This has private IP 10.0.0.1
> if_outbound = eth0 # This has a public IP
> sip_listen_port = 5060
> daemonize = 1
> silence_log = 0
> log_calls = 1
> user = nobody
> registration_file = /var/lib/siproxd/siproxd_registrations
> autosave_registrations = 300
> pid_file = /var/run/siproxd/siproxd.pid
> rtp_proxy_enable = 1
> rtp_port_low  = 7070
> rtp_port_high = 7079
> rtp_timeout = 300
> rtp_dscp = 46
> default_expires = 600
> debug_level =      0x00000ffe
> debug_port = 0
> 

I don't know about this. I got it working. but you have to use latest
CVS as some bugs were recently fixed.

> 	Thanks,
> 
> -Yenya
> 
-- 
 _      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