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/
