[Serusers] Re: First tests with nathelper

[Maxim Sobolev]

We have solved this issue by using symmetric rtp proxy integrated with 
nathelper module. We have not released it yet, but planning to do it in 
the nearest future. Stay tuned.

-Maxim

Ricardo Villa wrote:
> Hi Maxim,
> 
> I tried out the nathelper module and it works as described.  It certainly
> solves the problem of getting Natted ATAs to send SIP messages between each
> other.  Unfortunately I do not see how one can solve the problem of the
> Natted RTP stream.  For example, an ATA behind a NAT sends an INVITE message
> (to a UA that is out in the internet) saying that its audio port is 20000.
> Once the call is established (thanks to the nathelper module), the ATA
> starts generating the audio stream with source port 20000 but once it passes
> through the NAT the source port gets changed to some random number.  The
> remote user agent is trying to send its stream to port 20000 but the NAT
> drops it because it is not valid in its NAT table.
> 
> How have you solved this issue?
> 
> Thanks,
> Ricardo
> 
> ----- Original Message -----
> From: "Maxim Sobolev" <sobomax at portaone.com>
> To: <jaime at umtstrial.co.uk>
> Cc: <serdev at lists.iptel.org>; <serusers at lists.iptel.org>
> Sent: Thursday, May 01, 2003 5:18 AM
> Subject: [Serusers] Re: First tests with nathelper
> 
> 
> 
>>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
>>>
>>>
>>>
>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
> 
> 
> 
>