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

[kokoska rokoska]

Jonathan Palley napsal(a):
> Kokoska -
>   A few changes/fixes for the OPTIONS keep alive were recently made by 
> Anthm.  
> 

Thank you very much, Jonathan, for your reply!

I saw some discussion about it few days before, but I'm afraid it solves 
  something else.

> 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"/>
> 

Thank you again - this very useful option for some situations...

> 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 

Yes, this is what I remember from mentioned discussion.

> the SIP OPTIONS request wasn't completely formatted correctly (fixed). 

If you mean To: header I can say I know a little bit about it, because I 
reported it to jira with small (5 chars) patch :-)

>  Update and see if this helps you.
> 

I will do it in few minutes :-)

Best regards,

kokoska.rokoska


> What is the advantage of setting the periodicity of the NAT keep alive? 
>  I'm not sure I see it very clearly.
> 
> 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?  
> 
> JP
> On Apr 16, 2008, at 5:40 AM, kokoska rokoska wrote:
>>
>> Hi all,
>>
>>
>> First of all I have say I'm very impressed by FreeSWITCH SIP handling. 
>> It way differs from what I know from Asterisk :-)
>> A lot of my previous questions about adding/modifying SIP headers are 
>> irrelevant becasuse FreeSWITCH do the job automagically...
>>
>> -----
>>
>> Now why I want to say:
>>
>> I think about new feature which may (or may not :-) slightly off-load 
>> the FreeSWITCH in case of handling a lot of SIP clients behind NAT.
>>
>> If I understand my pcap dumps right, now in case of 10.000 UACs behind 
>> NAT FreeSWITCH tries to send more than 2000 OPTIONS per second to the 
>> UACs. If I don't miss something, it is too much, I think :-)
>>
>>
>> My idea is to use NAT-hack for only some of UACs, send NAT keep-alive 
>> OPTIONS for only UACs it realy need it (based on administrator decision) 
>> and make periodicity of NAT keep-alive packets configurable.
>>
>> I briefly looked into the sources and I think the solution could be like 
>> this:
>>
>> 1. Introduce new "per profile" variable "nat_keep_alive" meaning number 
>> of seconds between sending of OPTIONS.
>>
>> 2. Introduce new variable "sip_contact_ip" in Directory http post to 
>> xml_curl. This is helpful - if compared to "ip" - to decide if NAT-hack 
>> should be applied.
>>
>> 3. Introduce new variable "enable_nat_ping" which defaults to "yes". 
>> This var could be in replies to Directory http posts.
>>
>> 4. Remove sofia_reg_nat_callback from sofia_reg_check_expire and 
>> introduce independant call from sofia_profile_worker_thread_run driven 
>> by value of "nat_keep_alive" variable.
>>
>> 5. Modify DB table sip_registrations - add indexed TINYINT column 
>> "nat_ping" and write to this column value of variable "enable_nat_ping".
>>
>> 6. Select UACs for sending NAT keep-alive OPTINS from DB based by 
>> indexed column search instead of by expensive fullscan of table with 
>> "LIKE '%sometihng%'".
>>
>>
>> This is what I think could be useful. Any comments are welcome :-)
>> Expecially if somebody see it handy too or even works on something 
>> similar - to work together.
>> If you see I miss something important or you see any drawback in my 
>> suggestion, please tell me it :-). Thanks!
>>
>>
>> Best regards,
>>
>> kokoska.rokoska
>>
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org 
>> <mailto: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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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