[Serusers] nat test based on rfc1918 address in call-id field

[Richard]

> I don't understand in which cases you are not able to detect NAT?  We have
> stun-configured clients running behind symmetric NAT and so far I've seen
> most clients either do NOT attemp to rewrite themselves or they do
rewrite,
> but nat_uac_test("16") will catch them as the rewritten port is different
> from the source port.
 
The problem is that linux/netfilter uses port overload. It tries to reserve
the source port number whenever possible. So if an internal packet has
source 5060, it tries to keep use 5060 and only changes the source ip from
private to public. It only changes the source port if
protocol/src-ip/src-port/dest-ip/dest-port is not unique. For example, if
two phones go to different outside addresses, both will show up 5060 as the
source port. However if both go to the same address, the first one use 5060,
the second one has to change to make it unique.

For example, in the following packet, you only trace of behind NAT is the
Call-ID header.

80.12.34.5:5060-><server>:5060
INVITE sip:5551212 at test.org SIP/2.0
Via: SIP/2.0/UDP
80.12.34.5:5060;rport;branch=z9hG4bK8F3C30F6C252453BBA6E3F14DD775BA4
From: 2375900 <sip:2375900 at test.org>;tag=3667353892
To: <sip:5551212 at test.org>
Contact: <sip:2375900 at 80.12.34.5:5060>
Call-ID: 1B8E0416-C131-4F66-A7D9-C48614E23CC6 at 192.168.5.110
CSeq: 43281 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite release 1103a
Content-Length: 298

> One thing though: For example Grandstream will use stun to keep nat open
> on
> all but symmetric NAT.  If incoming keepalives (from the SIP server) are
> discarded, the NAT port assignment will time out.  GS must be configured
> with NAT Yes and empty STUN server and it will send keepalives to the SIP
> server.  I'm not sure why this is not done automatically when SNAT is
> detected...
Incoming keepalives would not refresh the conntrack timer, only an outbound
packet can. For this reason, we already disable the nat-ping in ser. We rely
on the UA to send out keepalive.

Thanks,
Richard