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

[Jonathan Palley]

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20080416/5c758135/attachment-0002.html