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 ?
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
