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" <[email protected]> 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 > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
