nathelper module has various tests for evaluating different headers in the
SIP message against the actual (network) source IP and port of the udp
packet. The tests all use RFC1918, thus nat_uac_test() is only useful if
you can make sure that the UAs behind NAT behave differently in how they
change via and contact headers than the one's not behind NAT. This is
slighly complicated and requires different setup up on UAs behind NAT and
not.
Or, you can modify nathelper to use your range of IP addresses by
replacing the definition of RFC1918 addresses with the ones you use where
UAs are behind NAT. Or, if you have a limited number of NATs, you can test
src_ip against those. Or, you can (if UAs use IP in contact and/or Vias) use
search() to look for ex. 10.54.*.* (behind NAT).
g-)
PS! Not basic question...
----- Original Message -----
From: "Ladislav Andel" <ladia6(a)centrum.cz>
To: <serusers(a)lists.iptel.org>
Sent: Saturday, December 03, 2005 11:50 PM
Subject: [Serusers] UAs and SER behind NAT
Hello,
I'm sorry for this basic question, but I have SER running on my LAN with
(RFC1918) addresses with UAs on the same network.
Then there are UAs registering from behind NAT to this SER on the LAN
network.
(SER is not listening on any public IP and it's just used in the private
network)
I came across this issue. If a UA on the LAN network is registering to SER
the logic of ser.cfg recognize the UA is behind NAT
after nat_uac_test.
If I want to introduce NAT traversal with RTPproxy for this private
network nat_uac_test will always return that the UA
is behind NAT because it has RFC1918 IP address. The RTPproxy will be used
at all times for UAs on the network or even I introduce STUN for NATed UAs
I know this is not a common usage of SER because it is invented to be used
on the global internet but I was just wondering is there any possibility
not to use RTPproxy at all times for UAs on the private network?
Maybe this is a silly question but it would help me for my testing
purposes with SER where I will not have to use my setup with usage of
public IPs.
Thank you for any thoughts.
Ladislav
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers