[Serdev] Can SER determine NAT type?

Greger V. Teigre greger at teigre.com
Thu Sep 22 17:51:09 UTC 2005


Hi Chris,
No, SER can never be really sure about the NAT type. Some clients will, as 
you say, add the detected NAT in the header. However, there are cases where 
a badly implemented STUN client (or a badly implemented NAT) will give the 
wrong answer.
    That being said, if you have control over the clients deployed in your 
network, you will know how the stun client(s) behave and what to expect.  if 
you use nat_uac_test("19"), you also include the test where ip is correctly 
fixed by the stun client, but where the source port of the sip message is 
different from the reported contact port (i.e. faulty STUN check). 
Unfortunately, some NATs are not implemented according to the STUN 
classification and you get unexpected results.  These NATs must be handled 
case by case basis.
    So, by using nat_uac_test("19") you should be pretty safe, but you need 
to test the UACs you support as well as what results you get for different 
NATs.  There is an RFC with a lot of results for different NATs that may 
help you, I don't recall the number right now.
g-)

----- Original Message ----- 
From: "Chris St Denis" <chris at aebc.com>
To: "Serdev" <serdev at lists.iptel.org>
Sent: Thursday, September 22, 2005 06:48 PM
Subject: [Serdev] Can SER determine NAT type?


>I want to use STUN as a primary nat solution, with the nathelper or
> mediaproxy module doing rewrites as a secondary/backup solution.
>
> However, this will not work for symmetric NATs. I want to proxy the rtp 
> data
> from these (and only these) kind of nat. Can SER determine that?
>
> My client adds a
> Warning: 399 spa "Restricted Cone NAT Dectected".
> Header to the register message (determined by stun), but that looks
> proprietary and not something I can expect to be the same from other 
> clients
> so I'm not sure I want to header match on that.
>
>
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
> 




More information about the Serdev mailing list