Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ghost calls on IPOCC10.1.2.3

Status
Not open for further replies.
lp_trd

lp_trd

Technical User
Jul 3, 2020
10
FR
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(72aee35ed2010200:DSPFScr_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(c364df5e42000000:poste7486:poste7486_7486:ws=Free : ls=SignedOn
15:30:39.876 TS_Routing TSPABXAgent(c364df5e42000000:poste7486:poste7486_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::eek: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.




 
Sort by date Sort by votes
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
 
Upvote 0 Downvote
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,
 
Upvote 0 Downvote
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?

 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

S
  • Locked
  • Question
IP Office Outgoing calls shows up as Spam Calls
Replies
0
Views
339
Sud10
S
Miguel O
  • Locked
  • Question
Establish route based on reference file lookup
Replies
0
Views
466
Miguel O
Miguel O
Dammy12
  • Locked
  • Question
How to stop agents from Disconnecting Calls
Replies
3
Views
340
janni78
janni78
lp_trd
  • Locked
  • Question
Installation of Avaya IP Office tools on IPOCC VM
Replies
2
Views
229
lp_trd
lp_trd
toniavaya
  • Locked
  • Question
Priority calls for agent grups and topics
Replies
4
Views
364
toniavaya
toniavaya

Part and Inventory Search

Sponsor

Back
Top