This is probably the most sensible cuase. a deadlock on transport
queues. Thanks for the info. Can you update the jira with this?
including the pertinent logs if possible.
On 08/03/2012 06:27 AM, andrewpit...@comcast.net wrote:
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
------------------------------------------------------------------------
*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 <mailto: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
<mailto:andrewpit...@comcast.net>> wrote:
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
<mailto: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 <tel:434.984.8426>
sip: helpd...@voice.myitdepartment.net
<mailto:helpd...@voice.myitdepartment.net>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org <mailto:sipx-users@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
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 <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com <http://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/
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
