On Jul 06, 2005 at 12:48, Jon Mansey jon@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