Okay, I uploaded the registrar and proxy logs from the time in question to the JIRA. AFAICT, the time this happened was at 2012-07-31T18:52:10.
A couple of things from sipXproxy.log that may or may not be pertinent: At 18:41:32, there are a couple of socket errors. Right before the hang at 18:52, there are a bunch of messages such as: "OsMsgQShared::doSendCore message queue 'AsynchMediaRelayRequestSender-16' is over half full - count = 99, max = 100" At 18:52:55, the destructor for an object of class OsBSemLinux (defined in sipXportLib) is called. The log entry says : "OsBSemLinux::~OsBSemLinux pt_sem_destroy returned 16 in task 2966346640" Hope this helps, Andy ----- Original Message ----- From: "Michael Picher" <mpic...@ezuce.com> To: "Discussion list for users of sipXecs software" <sipx-users@list.sipfoundry.org> Sent: Thursday, August 2, 2012 12:42:12 PM Subject: Re: [sipx-users] new patch for XX-10177 do you lick down a lot of ports? :-P i think these are all Polycom phones with 3.2.6 firmware. the only other thing a bit odd is they are coming through a Cisco ASA which is known to work but could be a question mark. I think they were going to try to route around this and then in through a pfSense box to see if the same thing happens. mike On Thu, Aug 2, 2012 at 12:28 PM, Tony Graziano < tgrazi...@myitdepartment.net > wrote: The malformed crap could easily come from a misconfigured or badly designed UA by the way. Also realize I have never seen it even with remote user traversal WHEN I lick down pps to port 5060 in the firewall to a sane functional number. One assumes you inspected the logs to verify there was no outside attempt to spam calls via the proxy (I.e. INVITE)? On Aug 2, 2012 12:05 PM, "andrewpitman" < andrewpit...@comcast.net > wrote: <blockquote> Hi Joegen! I dug around a bit in the code, and I might have a starting point for where to look for this... When this bug has manifested itself, we've been able to recover by restarting just sipXproxy, and not both proxy and registrar, so the issue doesn't seem to be with registrar. When the server stops responding to registration requests, sipXproxy loses its connection to sipregistrar on port 5070/tcp. sipregistrar remains listening on port 5070 and happily accepts the connection from sipXproxy when that's restarted. Also, based on Mike's comments when he visited the other day, it does not seem like this issue has shown up for installations which do not have many remote workers. In our configurations here, with some exceptions all of our phones are "remote workers," and in our setup we have to deal with both near and far end NAT traversal. Based on all that, and assuming the problem was probably with sipXproxy (or sipXtackLib) and probably had something to do with code dealing with NAT traversal, I came across the code in sipXproxy that deals with processing of forwardingrules.xml. If I'm reading the code (and comments) correctly, it looks like if a request does not have route state information (or if it does have NON-mutable route state AND the URI is in the local domain AND globally routable), forwarding rules is followed. Looking at the forwarding rules xml file, it looks like the catchall default is to send all other requests to the registry service. So, here's a thought... Given that forwarding to sipregistrar is the default, what kind of malformed crap could end up getting processed by that part of the code in sipXproxy? It seems to me that it would be more likely to bail there based on that. I'll continue my digging there, but I wanted to let you know. Would you mind having a look and let me know what you think? I'll forward along some logs from a recent hang, as well to make sure we're still on the right track. Thanks! Joegen Baclor wrote on Thu, 21 June 2012 12:50 > Then it is not the issue. However, that perl script just > became a DOS > attack tool against sipx so we need to accept the patch > just to prevent > what you have done from happening. Even if the patch > did not really > solve your issue, would you mind applying it and see if > you can fill up > /var/ folder with the patch active? > > Regarding the freezing issue, I'm gonna have to look > again. If you have > a hunch where I should be looking at, let me know. -- _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpdesk@voice.myitdepartment. net Helpdesk Customers: http://myhelp.myitdepartment. net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ </blockquote> -- Michael Picher, Director of Technical Services eZuce, Inc. 300 Brickstone Square Suite 201 Andover, MA. 01810 O.978-296-1005 X2015 M.207-956-0262 @mpicher < http://twitter.com/mpicher > linkedin www.ezuce.com ------------------------------------------------------------------------------------------------------------ There are 10 kinds of people in the world, those who understand binary and those who don't. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
