[Serdev] Re: [Serusers] Re: First tests with nathelper

Jiri Kuthan jiri at iptel.org
Sat Jun 7 08:42:50 CEST 2003


At 01:40 AM 5/15/2003, 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?

Use a symmetric device as UAS in the Internet. They will see direction=active
in ATA's SDP, ignore thus IP:port in there, and send their media to where ATA's
media come from. Note that there is no better help than media relay if both
parties are behind symmetric NATs.

-jiri


>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
>>
>
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev 

--
Jiri Kuthan            http://iptel.org/~jiri/  




More information about the sr-users mailing list