Error : Stacked long time

1. Brekeke Product Name and Version:3.5.8

2. Java version:1.8

3. OS type and the version:RHEL7

4. UA (phone), gateway or other hardware/software involved:NA

5. Your problem:

Call Flow: SIPP(UAC)-->BSS1-->SIPP(UAS)

I was doing load testing and I saw the following error messages. What is the meaning on "Stacked long time". What what is the reason and how can this be resolved?



1555961539010, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (rule:RULE1 & RULE2 & RULE3"), sip:800555281@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555281@192.168.2.158:5060, ,
1555961539020, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (rule:RULE1 & RULE2 & RULE3"), sip:800555282@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555282@192.168.2.158:5060, ,
1555961539031, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (Dispatcher), sip:800555283@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555283@192.168.2.158:5060, ,
1555961539039, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (rule:RULE1 & RULE2 & RULE3"), sip:800555284@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555284@192.168.2.158:5060, ,
1555961539049, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (Dispatcher), sip:800555285@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555285@192.168.2.158:5060, ,
1555961539059, 192.168.1.30:5070, INVITE, 603, Stacked long time: 120sec (rule:RULE1 & RULE2 & RULE3"), sip:800555286@192.168.2.158:5060, sip:sipp@192.168.1.30:5070, sip:800555286@192.168.2.158:5060, ,

Can you find these calls on the SIP Server's [Active Sessions] page?
If not, can you find them in the Logs page?

How many concurrent calls did you make at the same time?
Do you have enough network bandwidth between the test tool and the SIP Server?

I did not check if these calls were showing on the Active Session page.
I did not find these calls in the logs. I searched for 603 Decline, I did not see any entry.

I saw the errors after the test was done, so I dont know the how many total concurrent calls were in progress at the time of erors. Total calls were attempted were 29000 calls with 50cps.

Yes, I had plenty of bandwidth available between SIPP UAC and BSS as well as BSS ans SIPP UAS.

I can do the test again. Are there any additional debugs you you would like to see?. Let me know what are the things you would like to know.

Thanks

50 cps is not big number.

It seems you executed 3 DialPlan rules, RULE1 & RULE2 & RULE3.
What kind of rules are they?

Do you have any time consuming tasks in these rules?

RULE1 does the webget request and gets the phone number.
RULE2 does the pattern matching of the number. If it matches certain expression then it sends the response 404.
RULE3 routes the call to UAS which is SIPP running in UAS mode.

Have you enabled the Multiple Dispatcher?

I wan into an issue after deploying the multiple dispatcher. I guess the the application on the far end of webget screwed up. I will test again after the application is fixed.

How many dispatcher should I configure if I am expecting 50cps ?

> How many dispatcher should I configure if I am expecting 50cps ?

If each call triggers a $webget method to access to the application, it depends on how many concurrent HTTP requests the application can handle, and how soon the application returns a response.

If there is a delay, incoming calls will be stacked and so CPS will be decreased .

our application can handle 200 concurrent requests and it takes average of 2.5ms to process the request.

Do you still have the CPS issue?

FYI: you can check the web access's response time at webget's log.
The last filed of the log line is the process time of each request.

Also let you increase the value of [Number of Dispatchers]. For example, 50.