I think that both are a possibility. We recompiled the GNU without Debug to see if that would buy us some CPU cycles. We have waited to see if the GNU comes back and it does not. The process is running, but non-responsiveness. We are doing full proxy on a dual Xeon 3GHZ with 4 gig of memory. We are actually running 2 of them and the customer is splitting the call attempts between them, and we have seen both of them become non-responsive at the same time. We are able to log-in to the boxes and do what ever work needs to be done, so it is just the GNU that is unresponsive. Just can't take any more calls or telnet to the status port. The back-end could be a bottleneck with capacity, but I would expect that we would give back a cause code and go on. Could there be a timeout set to high that is filling up with calls in queue waiting to timeout? R. Todd Wallace -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Zygmuntowicz Michal Sent: Tuesday, February 08, 2005 10:25 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Non-Responsive Maybe you're running out of sockets or cpu usage is too high. Check port ranges and current socket usage and per process socket limits (netstat, ulimit). If you're using acct/auth, make sure your backend is not a bottleneck. ----- Original Message ----- From: "R. Todd Wallace" <rwallace@xxxxxxxxxxxxx> Sent: Tuesday, February 08, 2005 5:01 PM > We are having issues with the GNU becoming non-responsive. The service is > still active, but you can't go to the status ports and calls start > declining. Nothing is written to the gatkeeper.log file. If you stop the > service, it will not die and you have to kill with a "-9". We have the > GNU's compiled with debug, but a core is not generated. We are running > the > latest CVS and doing full media. This seems to come with a very heavy > load > / call charge rate. The only thing I see is that it scrolls the following > message across the screen to a call sticks: > > 2005/02/07 23:19:03.299 3 ProxyChannel.cxx(2757) RTCP > xxx.xxx.xxx.xxx:xxxx socket has no destination address yet, flush ignored > > I think this is normal, but not sure if we are having problems with > sockets > not freeing up or not freeing fast enough. > > Any Thoughts?? > > R. Todd Wallace ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/ ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/