Definitely something going on with the sipxchange user on this box (as mentioned below), but I had no problem running other development builds (for my companies product) after I noticed the issue with sipxchange (the inability to fork).
One concrete question: what can cause a "503 Maximum Calls In Progress" on a test system with no user traffic and 6 Polycom phones? None of the sip logs were growing when this was happening, there wasn't a lot of processes running (parented by the manager or otherwise). Maybe there's an fd leak? -Eric On Dec 18, 2009, at 5:41 PM, Scott Lawrence wrote: > On Fri, 2009-12-18 at 16:34 -0600, Eric Varsanyi wrote: >> Sorry for incomplete information. >> >> Yes, the call comes in to the SPA3102 'fxo1' at 192.172.252.21 and it >> is programmed to dial 0...@... to get the auto attendant. I enter '200#' >> to transfer to extension 200 "Kitchen", this is 192.172.252.42. The >> sipX code is running on 192.172.252.163. >> >> Here's another extract I did with "d3 ~/sip1/INSTALL/bin./sipx-trace >> -a -o /tmp/poly2.xml 5434d8c5-c89e2db7". >> >> One other data point, for some time over the last day something (that >> I couldn't track) ran wild and all my shells logged in as sipxchange >> started reporting 'out of resources' when they tried to fork any >> command. I could log into the box (which was set up by the EDE stuff) >> on another account w/o any issue and run things, there wasn't a huge >> number of processes active per ps auxww (nor a horde of zombies). This >> is quite a mystery and after an 'sstop' / 'sstart' the problem went >> away (for now). I don't now if this is related but its worth >> mentioning. The box has 2T of disk on a SAS array in the root FS >> (which is as expected mostly empty) and 32G of physical RAM (of which >> very little is in use according to top and /proc/meminfo). >> >> I notice that freeswitch is dropping core files now and then in the >> log directory, but they don't seem related to the 'REJECT' button >> issue (I haven't dug into that issue yet). > > You've got some wider system issue - the call trace looks perfectly > normal as far as the phone is concerned. The reject returns a normal > 486 Busy response, and then the call is forked to voicemail, but the > voicemail server returns: > > SIP/2.0 503 Maximum Calls In Progress > > Since Busy is a 'better' status than the 503, the proxy ends up > returning the busy to the caller (SIP only allows a proxy to return one > error response to a request). > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
