[Freeswitch-users] New feature - NAT handling, keep-alive OPTIONS

[kokoska rokoska]

I'm very sorry, Jonathan, I sent previous e-mail accidentaly before I 
wrote all I want, so story continues:

Jonathan Palley napsal(a):
> Kokoska -
>   A few changes/fixes for the OPTIONS keep alive were recently made by 
> Anthm.  
> 
> A new option for the UAC (which, as previously mentioned can either go 
> in the directory or the sip profile config) is:
> 
>     <param   name="unregister-on-options-fail"   value="true"/>
> 
> This will set a UAC to expire should the options requests timeout/fail. 
>  There were also a few bugs that were fixed.  For example, the OPTIONS 
> were sent to clients whose registrations had already expired (fixed) and 
> the SIP OPTIONS request wasn't completely formatted correctly (fixed). 
>  Update and see if this helps you.
> 
> What is the advantage of setting the periodicity of the NAT keep alive? 
>  I'm not sure I see it very clearly.
> 

This comes from my experience:
Normaly is enough to send keep-alive OPTIONS, lets say, every 20 
seconds. But in few networks I see so agressive NAT, that closes UDP 
conenction in about 10 seconds of inactivity. So if you need to handle 
this kind of UACs, you need keep-alives every 9 seconds.
This is just my few cents...

> Also, while in principle the %NATHACK% is an expensive operation I 
> wonder just how many UAC you need to have registered before it really 
> becomes a factor?  
> 

If I'm not wrong in my calculation (included in first e-mail), it could 
become a bottle-neck in case of about 5-10.000 NATed UACs.
This comes from my playing with OpenSER (but with slightly higher amount 
of UACs), where I need to disable NAT keep-alives and send them from my 
own daemon to just few of NATed UACs. And I'm affraid FreeSWITCH can't 
be much faster than OpenSER.
BTW: Do you have (or someone else) any experience with handling large 
population of NATed UACs? If yes, could you share it? It could help me 
much...


Thanks once more, Jonathan, for your reply!

Best regards

kokoska.rokoska