Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

?
sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
^
Forum Index » Server Platform » outstanding request limit exceeded   XML
 
Author Message
WeiZhu



Joined: 10/07/2014 07:17:32
Messages: 1
Offline

Dear all,

We are using TSAPI to control 96x1 SIPCC agent. All of the release of Avaya Aura core is R7.0 include SM, CM, AES, SMGR. only one CTI link in the this test system.

Now the TSAPI can control 9611 SIPCC to make call, hold and retrieve. After retrieved call, we try to hold again, the operator is failed. we got a error message is : outstanding request limit exceeded.

Need help to analyze the cause.

William
[Thumb - 1.jpg]
 Filename 1.jpg [Disk] Download
 Description No description given
 Filesize 237 Kbytes
 Downloaded:  35 time(s)

[Thumb - 4.jpg]
 Filename 4.jpg [Disk] Download
 Description No description given
 Filesize 240 Kbytes
 Downloaded:  60 time(s)

[Thumb - 5.jpg]
 Filename 5.jpg [Disk] Download
 Description No description given
 Filesize 243 Kbytes
 Downloaded:  43 time(s)

MartinFlynn



Joined: 30/11/2009 05:00:18
Messages: 1385
Offline

According to the TSAPI PG:

OUTSTANDING_REQUEST_LIMIT_EXCEEDED (44) – The client attempted to put a third party on hold (two parties are on hold already) on an analog station.

However, this does not seem appropriate to your situation.

I think I have found in the past that Communication Manager sometimes uses this error code when it does not have a more appropriate one available. When something unexpected happens.

As you are using SIP stations, it is possible that the error originated on Session Manager or the station itself. So, I would suggest that you may find it useful to do some SIP tracing to try to find the source. Session Manager does have a SIP trace facility that you can use but I do not know much about it.

Martin
MartinFlynn



Joined: 30/11/2009 05:00:18
Messages: 1385
Offline

It may also be a good idea to make sure that Communication Manager generated the error and not AE Services. It is very unlikely that AE Services generated an error like this but I think I have come across a case in the past where it did.

To check this, enable TSAPI tracing on AE Services. Then check the g3 trace file and make sure that AE Services sent the second Hold request, as an ASAI message, to Communication Manager and that Communication Manager responded with an error.

You can get instructions in the Devconnect Product FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?". It is in the "FAQ: AE Services TSAPI -> General" section.
 
 
Go to: