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

Jonathan Palley jpalley at idapted.com
Tue Apr 15 23:30:42 PDT 2008

I get the feeling that some of these edge optimizations are,  
rightfully, not the top priority for the core team.  If you make  
these changes I'm happy to help test as all of our users are behind a  
NAT.  Right now we don't have enough users to justify doing this  
optimization ourselves though.

As for keeping the UDP connection open I recommend having the client  
send "blank" UDP packets and setting the interval there.

On Apr 16, 2008, at 2:06 PM, kokoska rokoska wrote:

> 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  
>> 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
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- 
> users
> http://www.freeswitch.org

More information about the FreeSWITCH-users mailing list