Ghost calls on IPOCC10.1.2.3

[lp_trd]

Hello guys,

I'm having an issue with a customer's installation.
There is an IP Office 11.0.4.1 and a IPOCC 10.1.2.3. This is an install from scratch for the IPOCC.

The solution works most of the time correctly but from time to time (about once a week) a call that no longer exists on the IPO remains in the IPOCC queue. and it blocks all new calls that are no longer distributed to agents while they are available.
There is then the possibility to assign new calls manually to agents. About the "ghost" call, this is not possible to assign it manually.
This call was killed when the block period started. But otherwise the only way is to restart the watchdog service.

In the logs, I found some errors:

15:30:18.598 CHAP_SIP_FrameworkError [0x00004874] ALSIP: CLineSet::RenegotiateMedia:
15:30:18.598 CHAP_SIP_FrameworkError [0x00004874] SIGADAP: RenegotiateMedia
15:30:27.841 TS_TSI T->A: TSVEP_impl(72aee35ed2010200SPFScr_XXX-Dissuasion:XXX-Dissuasion): EPTCInfoScriptStartedEvent:
15:30:27.842 TS_TSI T->A: TSVEP_impl(d4bbc25e41000000:TOPIC1:6002): EPTCInfoScriptStartedEvent:
15:30:38.872 K_Routing T->K: ReqMove(TS=TS_IPO_PBXServer, ep=TOPIC2,
15:30:38.872 TS_Routing TSPABXAgent(c364df5e42000000oste7486oste7486_7486:ws=Free : ls=SignedOn
15:30:39.876 TS_Routing TSPABXAgent(c364df5e42000000oste7486oste7486_7486:ws=Free : ls=SignedOn
15:30:39.877 K_Routing T->K: ReqMove(TS=TS_IPO_PBXServer, ep=TOPIC2,
15:30:40.888 CHAP_SIP_Error [0x000085C0] ocSIPUAController::zInitiateConsultTransfer callID=3464,
15:30:40.888 CHAP_SIP_FrameworkError [0x000085C0] ALSIP: CLineSet::RenegotiateMedia:
15:30:40.888 CHAP_SIP_FrameworkError [0x000085C0] SIGADAP: ERROR:
15:30:40.888 TC_Error 024.000.0325 [0x000085C0] ocAdapter::zSSTransferCall(IPO-SIPEXT-IP-1)
15:30:40.889 TS_TAPIEventing TSContextObjAgent:nFailure: errCode=-15:ResourceBusy dest=Poste7486:7481,
15:30:40.890 TS_TSI T->A: TSTASKEPX_impl(TSPEP_impl(0a24dd5e43000000:7481:7481)): EPTaskTagSetEvent:
15:30:41.888 CHAP_SIP_Error [0x000085C0] ocSIPUAController::zInitiateConsultTransfer callID=3464,
15:30:41.888 CHAP_SIP_FrameworkError [0x000085C0] ALSIP: CLineSet::RenegotiateMedia:
15:30:41.888 CHAP_SIP_FrameworkError [0x000085C0] SIGADAP: ERROR:
15:30:41.888 TC_Error 024.000.0325 [0x000085C0] ocAdapter::zSSTransferCall(IPO-SIPEXT-IP-1)


My questions are:
- It says ressource Busy but the agent is available and can take the other calls manually provided. Obviously there is no one at the other end of this call but why this one is not killed by the system ?
- What SIGADAP Error means ? Can that be a network problem ?

Thank you in advance.

 

[janni78]

I haven't had this issue in later releases, also whenever I've had ghost calls they never blocked new incoming calls.

Usually bad TaskFlow or IVR causes issues like this.

Problem is, it's nearly impossible for me to figure out what the issue is without access to the system, so the best bet is to contact Avaya when it happens.


"Trying is the first step to failure..." - Homer

 

[lp_trd]

Hello Janni78,

First of all thank you for your quick answer.
For the moment I have not found the root of this issue.
Analaysing the logs, it seems the issue happens when the reception service of my final customer try to blind-transfer a call to the IPOCC topic. Sometimes something happens and then the call no longer exists in the IP Office while it is still present in the IPOCC Topic Queue.

I will try to find a workaround.

Regards,

 

[dc29]

Hi Janni78,

I'm experiencing a similar issue as you in regards to a ghost call in one of our topics. This issue is extremely rare in our environment, however, when it occurs, I find the only way to rid of this is to restart the Watchdog service. The IPOCC VEA service handles connections to the topics/queues and may fix this issue but I'm not certain. As you probably know, restarting any of the IPOCC services independently usually breaks IPOCC and you eventually will need to restart Watchdog.

I tried adding a block period for that topic but it did not clear it. Have you been able to find a workaround?

 

[janni78]

Guess the easier way to figure out where the call is, is by setting up a Queue view.
It should show what the call is doing, if it's in an IVR or playing announcements etc.

Bad IVR design is usually the main cause of stuck calls, also depending on how you configure your skills / tags the may or may not keep settings when a call is transferred.

"Trying is the first step to failure..." - Homer