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 >> [email protected] >> <mailto:[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 _______________________________________________ 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
