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