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

[Jan Kasprzak <kas fi muni cz>]

Damien Sandras wrote:
: If I was you I would check the bindings.
: 
	I am sorry I don't understand - which 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.

	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.

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

	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

	Thanks,

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> Specs are a basis for _talking_about_ things. But they are _not_ a basis <
> for implementing software.                              --Linus Torvalds <