Did you know that you can set the params and variables separate in each <user> if you wish. The default example where it puts them in the <domain> is not mandatory, when you add params to the domain it implies every user in that domain.
On Tue, Apr 15, 2008 at 4:40 PM, kokoska rokoska <[EMAIL PROTECTED]> 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 > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:[EMAIL PROTECTED] <[EMAIL PROTECTED]> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]<[EMAIL PROTECTED]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> iax:[EMAIL PROTECTED]/888 googletalk:[EMAIL PROTECTED]<[EMAIL PROTECTED]> pstn:213-799-1400
_______________________________________________ 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
