Long Ringing Duration to Contact Centers Route Points (IPCC-Express)

Unanswered Question
Aug 27th, 2010

Hi,

I have a Customer who has the following issue.

The Customer has a range of DDI numbers which come into a Voice Gateway configured with a  1x 30ch Pri-Rate E1.

There is an intermittent fault whereby the Incoming Call Alerting continues to ring on the B-Channel for at least 40 seconds before the contact center

Route Point processes the call. The call center has a maximun of 50 Jtapi CTI Ports and during the busy period there are at least 7 call center agents and possibly 4/5 of those agents handling calls.  The Customer's IPCC-Ex is not a busy system.

There is no pattern to the long ring duration i.e the Contact Center Route points will process half a dozen calls after a single burst of ringing then the next call will continue to alert for 40 seconds before the Contact center process the Call.

The IPCC-Ex is running 4.5(2) SR02_Build014, which is the latest release. The SR was installed about a month ago because the customer had issues with calls disconnecting. The Cct has been tested by the Telco and appears to be ok. there are no errors on the E1 controller and the debug shows the incoming call Alerting and call setup. The CPU Process of the Gateway is < 10%.

The only thing I can think of trying next is swapping the E1 cct. The Customer has a 2nd cct with the Telco which is in place for resilience and is not being used.

any suggestions welcome

Regards

Charles

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
jtesar Fri, 08/27/2010 - 14:36

Charles -

Your best bet might be to open a TAC case.  From a troubleshooting perspective, TAC will need the following:

Detailed CM & CTI Manager Traces:

http://cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094e89.shtml

UCCX:

MIVR Traces with SS_TEL, ENG, SS_RM, SS_RMCM, SS_CM, ICD_CTI all enabled.

It might not hurt to get debug isdn q931 from the gateway as well.  However, the gateway is at the mercy of when CM tells it that the call is answered.

TAC will need this and details of the call, calling party, called party, time of the call to investigate.

-jt

Aaron Harrison Mon, 08/30/2010 - 09:20

Hi

Are there any steps in your script preceding the 'accept' step? The system will ring until that step is hit, so if you have anything before that it could be a source of delay.

Regards

Aaron

luisso Sun, 09/19/2010 - 12:20

Did you get resolution to this issue? I'm having the same issue with 7.0.1 SR5.

charles-moore Mon, 09/20/2010 - 16:37

Hi Luisso,

The fault I have is on IPCC express 4.5 sr2, however I have pulled the trace files and I believe I've found the fault which is causing the Extended

RNA delay of up to 40 seconds. This will need to be raised as a TAC for sure.

Regards

Charles

luisso Mon, 09/20/2010 - 16:42

thanks for replying. How did TAC fix it?  Was it a quick fix?

charles-moore Mon, 10/04/2010 - 13:55

Hi All, & Hi Luisso.

Cisco TAc found the problem see below:

The Customer had a few scripts with DSN entries i.e the script called upon a DataSource Names.

The customer at some point in the past removed the DSN from the script or may have removed the script, nervertheless the end result

has meant the Contact Centre keeps trying to Create a Datasource for the Non-Exsisting DSN's which results in the Contact Centre utilising a large amount of the system resources.

Basicly if a DSN is no longer used in script, the admnistrator needs to complete some house keeping and remove the entries from ODBC.

From:[email protected]]
Sent: 27 September 2010 01:26
To: Charles; Charles Moore
Subject: RE: [WARNING : MESSAGE ENCRYPTED] RE: Sev 3 SR 615547643 : UCCX// configuration assistance

Hi Charles

Checking the logs looks like the script is taking 30+ seconds to answer  the call

================

15:35:02.885 BST %MIVR-SS_TEL-7-UNK:Call.accepted() JTAPICallContact[id=50536,type=Cisco JTAPI Call,implId=705551/2,active=true,state=CALL_RECEIVED,inbound=true,handled=false,locale=en_GB,aborting=false,app=App[name=Introducers2,type=Cisco Script Application,id=15,desc=Introducers2,enabled=true,max=20,valid=true,cfg=[ApplicationConfig........

15:35:34.979 BST %MIVR-SS_TEL-7-UNK:Call.answered() JTAPICallContact[id=50536,type=Cisco JTAPI Call,implId=705551/2,active=true,state=CALL_ANSWERED,inbound=true,handled=false,locale=en_GB,aborting=false,app=App[name=Introducers2,type=Cisco Script Application,id=15,desc=Introducers2,enabled=true,max=20,valid=true,cfg=[ApplicationConfig.......

===============

and the reason it’s taking that long is because in between its using all the resources to create DSN connection to external database and failing

========

15:33:47.446 BST %MIVR-SS_DB-3-CANNOT_CREATE_DATASOURCE_FOR_DSN:Cannot create Datasource for given DSN: DSN Name=IVR_CC

15:33:47.649 BST %MIVR-SS_DB-3-CANNOT_CREATE_DATASOURCE_FOR_DSN:Cannot create Datasource for given DSN: DSN Name=IVR_Test_EBA

======

Can you confirm if these DSN connection are used by UCCX, if not can you delete them and see if it helps resolving the issue.

These are the DSN names configured to create an ODBC connection to the external database from the UCCX server.

Following are the steps to check

start - programs - administrative tools - Data Sources (ODBC) - System DSN

Let me know how it goes

Thank you

[email protected]

Cisco Systems
Technical Support Engineer
TAC EAST - UCCX
Office:
Shift: 8:00 am - 5:00 pm(EST)

luisso Wed, 10/06/2010 - 09:34

Thank you so much for your response. My problem sort of went away and it may have been fixed when I cleaned up some of the datasources I had.

Regards

Luis

charles-moore Mon, 10/04/2010 - 13:56

Hi Luisso.

Cisco TAc found the problem see below:

The Customer had a few scripts with DSN entries i.e the script called upon a DataSource Names.

The customer at some point in the past removed the DSN from the script or may have removed the script, nervertheless the end result

has meant the Contact Centre keeps trying to Create a Datasource for the Non-Exsisting DSN's which results in the Contact Centre utilising a large amount of the system resources.

Basicly if a DSN is no longer used in script, the admnistrator needs to complete some house keeping and remove the entries from ODBC.

From:[email protected]]
Sent: 27 September 2010 01:26
To: Charles; Charles Moore
Subject: RE: [WARNING : MESSAGE ENCRYPTED] RE: Sev 3 SR 615547643 : UCCX// configuration assistance

Hi Charles

Checking the logs looks like the script is taking 30+ seconds to answer  the call

================

15:35:02.885 BST %MIVR-SS_TEL-7-UNK:Call.accepted() JTAPICallContact[id=50536,type=Cisco JTAPI Call,implId=705551/2,active=true,state=CALL_RECEIVED,inbound=true,handled=false,locale=en_GB,aborting=false,app=App[name=Introducers2,type=Cisco Script Application,id=15,desc=Introducers2,enabled=true,max=20,valid=true,cfg=[ApplicationConfig........

15:35:34.979 BST %MIVR-SS_TEL-7-UNK:Call.answered() JTAPICallContact[id=50536,type=Cisco JTAPI Call,implId=705551/2,active=true,state=CALL_ANSWERED,inbound=true,handled=false,locale=en_GB,aborting=false,app=App[name=Introducers2,type=Cisco Script Application,id=15,desc=Introducers2,enabled=true,max=20,valid=true,cfg=[ApplicationConfig.......

===============

and the reason it’s taking that long is because in between its using all the resources to create DSN connection to external database and failing

========

15:33:47.446 BST %MIVR-SS_DB-3-CANNOT_CREATE_DATASOURCE_FOR_DSN:Cannot create Datasource for given DSN: DSN Name=IVR_CC

15:33:47.649 BST %MIVR-SS_DB-3-CANNOT_CREATE_DATASOURCE_FOR_DSN:Cannot create Datasource for given DSN: DSN Name=IVR_Test_EBA

======

Can you confirm if these DSN connection are used by UCCX, if not can you delete them and see if it helps resolving the issue.

Let me know how it goes

Thank you

[email protected]

Cisco Systems
Technical Support Engineer
TAC EAST - UCCX
Office:
Shift: 8:00 am - 5:00 pm(EST)

Actions

This Discussion