7 Jul
2005
7 Jul
'05
5:04 p.m.
On Jul 06, 2005 at 12:48, Jon Mansey <jon(a)tigrisnet.net> wrote:
Hi Serusers,
I have 2 ATAs, one is V3.1 and one is V3.2, they are both behind NAT and are
behaving differently when registering. With 3.2, the nat_uac_test does not
apparently detect it is behind NAT and leaves the flag at 0 in the location
table. V3.1 works fine.
I can see why nat_uac_test() may be failing, because the ATA seems to have
auto-magically detected its public IP and is using it in the via: header,
thus receive!=via test fails! Also the contact has the public IP, so the
RFC1813 test fails. I have not configured the NAT IP or server in the ATA as
the NAT public IP is dynamic.
Although the v3.2 ATA seems to have figured out its public IP, it still uses
its private IP in the INVITE sdp c= headers, so we get no media. And because
the nat flag is 0, the rtpproxy doesn't kick in and fix things. Notice the
call-id of the register message includes the private ip.
Anyone familiar with ATA firmware versions and features know the magic
incarnation to shut off the "auto-detect public IP", ahem, "feature"
in
v3.2? Or any other suggestions for how to make nat_uac_test() get a positive
when it gets one of these smart REGISTERs from behind NAT?
Im running the old version of SER 0.8.12 still where nat_uac_test only has 1
2 or 3 options, not the new one that has "19", would that make a difference,
upgrading to v0.9?
Yes, it would.
If you want to test for private ip in sdp then you have to add 8 to your
nat_uac_test options ( 1|2|8 =>11 => nat_uac_test(11)). The test sdp
for private ip flag is supported starting with ser 0.8.14.
ser 0.9.x adds the test port in via != received port flag (16). This is
usefull to catch UACs that detect somehow the ip of the nat but not the
right port (e.g. they are behind symmetric NATs, their nat detection
is buggy and they don't revert to private ips as they should).
So to be on the safe side, upgrade to 0.9.x and use nat_uac_test(27)
(27= 1 | 2 | 8 | 16).
Andrei