[Users] NAT (again)

Mark Kent mark at noc.mainstreet.net
Thu Aug 24 18:21:32 CEST 2006


Klaus Darilion typed:
>> If a phone is behind sym NAT it should not use public IP:port in
>> the message, as they are wrong. The phone should use private IP
>> address to allow NAT traversal in the SIP proxy.

So, I take that to mean I should turn off NAT support (i.e., STUN) in
the Grandstream.

What's the general feeling about coding in openser.cfg to pick up the
various kinds of phones (I see an example looks for "Cisco ATA") and do
something different for each.  I don't want to do it... this is more
of a "Best Common Practices" question.

>> If you do NAT traversal for all clients, than it should not matter. 

I do...

Bogdan-Andrei Iancu wrote:
>> you might consider using force_rport() function to overcome the port 
>> problem - openser will use the received port instead of the one 
>> advertised in Via.

I use that, I'm using the template from the nathelper-rtpproxy config
that I emailed about a few days ago.  I do it before t_relay(), I do it
in the REGISTER before the challenge, ...  ooops, turns out I don't
do it before the challenge for INVITE.   I'll give that a shot.

>> include in your nat_uac_test() the flag 16 . see:

I'm not doing any testing, I'm forcing NAT behavior for all right now.
So... is there a problem with that?  That is, is there a problem with
using all the NAT support features in nathelper, other than the tests,
even if the EndPoint is not NATed?

Thanks,
-mark






More information about the sr-users mailing list