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@lists.freeswitch.org <mailto: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
------------------------------------------------------------------------
_______________________________________________ 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