stipus wrote: > I have been trying to stress test my application using Sipp today. > http://sipp.sourceforge.net/index.html > > The scenario is very simple: > > |(1) INVITE | > |------------------>| > |(2) 100 (optional) | > |<------------------| > |(3) 180 (optional) | > |<------------------| > |(4) 200 | > |<------------------| > |(5) ACK | > |------------------>| > | | > |(6) PAUSE | > | | > |(7) BYE | > |------------------>| > |(8) 200 | > |<------------------| > > I very quickly got 486 busy error response to INVITES. > > I found the following code in CallManager.cpp: > > if(getCallStackSize() >= mMaxCalls) > > { > > OsSysLog::add(FAC_CP, PRI_DEBUG, "CallManager::handleMessage - The call > stack size as reached it's limit of %d", mMaxCalls); > > Send 486 Busy error (I didn't paste all code for this). > } > > In sipxtapi.log, I can find the call stack size limit reached message, a few > lines before the first 486 busy message is sent. > > I found that call manager mMaxCalls was initialized to 10 from Sipaxtapi > sipxInitialize() when the Call Manager object is created. > > I tried to change the value to 32, 64, 128, 256 ... etc... but in the end, I > always got 486 busy errors although SIPP was configured to a maximum of 30 > simultaneous calls. Each time I increased the value, it took longer before I > got the error, but I always got it ! > > I tried to enable TroubleShooting mode to print the call stack (registry key > HKLM/Software/Pingtel/sipxUA/TroubleShootingMode=1. > > First thing I had to do was to comment the OsReadLock lock(mCallListMutex); > in the CallManager::printCalls() method, as this readlock is nested in a > writelock... and this caused immediate deadlock. > > Then, I found from the log that the call stack was growing although > sipxCallDestroy() had been called for each call. I could find many "Failed > to find call to remove from stack" errors in the log. After about 1200 > calls, I can find 256 active calls left on the stack although there were > never more than 30 active calls. > > I have been fighting this for hours, but I still don't have a clue why the > calls that need to be destroyed cannot be found on the stack. The only thing > I found is a weird delay(20) in CallManager::changeCallFocus() with a > frightening comment. > > Any idea what could cause this problem in the Call Manager ?
Thanks for discovering this problem, I will have a look at it today. I was able to recreate the problem with sipp myself. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
