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