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 <[email protected] > 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" <[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].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> > Blog: http://blog.myitdepartment.net > > _______________________________________________ > sipx-users mailing list > [email protected] > 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 ------------------------------------------------------------------------------------------------------------ There are 10 kinds of people in the world, those who understand binary and those who don't.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
