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