[Serusers] Re: First tests with nathelper

[Maxim Sobolev]

I've just committed into the cvs the autopinging feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:

modparam("nathelper", "natping_interval", N)

Where N is some non-zero interval in seconds (usually 15-30 should
be OK).

Thanks!

-Maxim

On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime at umtstrial.co.uk wrote:
> Hello Maxim,
> 
> I have been trying your module on one server with a customised
> configuration, very similar to the default one in nathelper.cfg. Actually,
> I'm trying to connect through a NAT to a server running SER with the
> nathelper module. The overall configuration looks like this:
> 
> UA1 --- NAT --- SER (proxy and registrar)
> UA2  |
> 
> UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
> have port forwarding whatsoever.
> 
> I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
> INVITE messages. The nathelper adds rport and received to the Via field,
> so any response from the server gets routed correctly to the appropriate
> destination (that is, the NAT external interface).
> 
> REGISTER's Contact is stored at registration and the 200 OK reaches the
> initiating client through the NAT.
> 
> However, any other SIP message involving a database lookup into "location"
> will try to relay the message to the natted client, which is not reachable
> from the SER proxy (see diagram above). I think this could work if in
> location table you stored the "received" and "rport" values instead of the
> "Contact" field received when regitering (if that does not go against
> standards...). Then, just keep alive the NAT binding somehow (I think you
> where mentioning it in a previous email).
> 
> Does this sound resonable? Making this scenario work would allow people at
> home with simple NAT's to use a public proxy (like Iptel's) and its
> services (Instant Messaging and Presence mainly)...
> 
> Jaime
> 
> 
>