Call not landing on Agent Phone

Unanswered Question
May 8th, 2009

Hi,

ICM 7.5

CVP 7.0

VXML5350

CCM 6.1.3

Gatekeeper (GUP)

My setup is not able to land call on agent phone, the phone goes to reserved state but is not able to receive call.

I assume that the ICM is reserving the call as it is showing the Label (agent phone line number) in router log but the CVP is not able to get the lable or not sending it to Gatekeeper.

As soon as the Agent becomes ready the system drops the call.

Here is log from CVP.

7:12:29 Trace: 00000012: CALLFLOW: IP transfer - Agent hung up : DNIS = 7001234567152 : GUID = 2F9064F80304001F20345DD2A3A0591F : CID = 9FE79F26397F11DE83D10022915807EC

17:12:29 Trace: 00000012: CALLFLOW: Call ended : DNIS = 7001234567152 : GUID = 2F9064F80304001F20345DD2A3A0591F : CID = 9FE79F26397F11DE83D10022915807EC

17:12:29 Trace: 00000011: CALLFLOW: Call successfully established (slow start) : DNIS = 8881 : CID = 9FE79F26397F11DE83D10022915807EC

17:12:31 Trace: 00000011: CALLFLOW: Disconnecting caller because agent hung up. : DNIS = 8881 : CID =

The disconnect error is like.

17:22:46 Trace: DEVICE_TARGET_ABORT_IND message received from Peripheral(5000) CRSCallID(Date 149144 ,ID 696), NetworkTarget(5000),MRDomain(1), Agent(5009).

The Gatekeeper is not showing the request for the Label (agent phone number).

Here is debug from gatekeeper.

May 8 08:41:02.696: gk_rassrv_arq: arqp=0x447C5298, crv=0x320, answerCall=0

May 8 08:41:02.696: gk_dns_query: No Name servers

May 8 08:41:02.696: rassrv_get_addrinfo: (8881) Tech-prefix match failed.

May 8 08:41:02.696: rassrv_get_addrinfo: (8881) Matched zone prefix 88 and remainder 81

May 8 08:41:02.696: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x45932540

May 8 08:41:02.696: rassrv_arq_select_viazone: matched zone is SIDEA, and z_invianamelen=0

May 8 08:41:02.696: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45932540

May 8 08:41:02.700: rassrv_arq_select_viazone: matched zone is SIDEA, and z_outvianamelen=0

May 8 08:41:02.904: gk_rassrv_arq: arqp=0x447C5298, crv=0x3A90, answerCall=1

May 8 08:41:02.908: gk_rassrv_irr: irrp=0x447C5298, from 10.20.63.100:51859

May 8 08:41:02.916: gk_rassrv_brq: state = 0xF

May 8 08:41:02.916: gk_rassrv_brq: brqp=0x45254CE0, crv=0x3A90, bandWidth=1280

May 8 08:41:02.928: gk_rassrv_arq: arqp=0x447C5298, crv=0x3A91, answerCall=0

May 8 08:41:02.928: gk_dns_query: No Name servers

May 8 08:41:02.928: rassrv_get_addrinfo: (70012345671049) Tech-prefix match failed.

May 8 08:41:02.928: rassrv_get_addrinfo: (70012345671049) Matched zone prefix 7001234567 and remainder 1049

May 8 08:41:02.928: rassrv_arq_select_viazone: about to check the source side, src_zonep=0x45932540

May 8 08:41:02.928: rassrv_arq_select_viazone: matched zone is SIDEA, and z_invianamelen=0

May 8 08:41:02.928: rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x45932540

May 8 08:41:02.928: rassrv_arq_select_viazone: matched zone is SIDEA, and z_outvianamelen=0

May 8 08:41:02.928: gk_rassrv_brq: state = 0xF

May 8 08:41:02.928: gk_rassrv_brq: brqp=0x45254CE0, crv=0x320, bandWidth=0

May 8 08:41:02.932: gk_rassrv_arq: arqp=0x45A0806C, crv=0x1E7, answerCall=1

May 8 08:41:02.944: gk_rassrv_irr: irrp=0x447C58B8, from 10.20.63.101:56715

May 8 08:41:02.948: gk_rassrv_brq: state = 0xF

May 8 08:41:02.948: gk_rassrv_brq: brqp=0x45254CE0, crv=0x320, bandWidth=1280

May 8 08:41:02.952: gk_rassrv_brq: state = 0xF

May 8 08:41:02.952: gk_rassrv_brq: brqp=0x45254CE0, crv=0x3A90, bandWidth=1280

May 8 08:41:02.952: gk_rassrv_brq: state = 0xF

May 8 08:41:02.952: gk_rassrv_brq: brqp=0x45254CE0, crv=0x3A91, bandWidth=1280

May 8 08:41:05.224: gk_process_read_event: Recd event from altgk

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
csshenoy80 Sat, 05/09/2009 - 01:41

Hi

The issue seems to be that the Call is not being sent to the Call Manager (IP Phones).

Do you see the agent state put into "Reserved" and then turned into "Not Ready" and some PIM messages?

Check the Endpoint registration for the Call Manager on the Gatekeeper and check the Gatekeeper Zone Configuration.

Issues might be

1. The CVP is trying to transfer the call to IP Phones using the Call Manager signalling, however not able to find the call manager.

2. Check the CSS configured for the CVP routelist.

Thanks.

Chris Deren Sat, 05/09/2009 - 06:00

Please post your GK configuration.

are you using tech-prefix on GK, if so are you properly stripping it on CM when call arrives?

Do you have device target properly configured with labels for the VRUs and CM in UCCE, or if you are using targeting rule is that properly setup with proper range and routing clients?

Chris

sandeep pokhriyal Sat, 05/09/2009 - 06:47

Hi,

Here is configuration from gatekeeper.

gatekeeper

zone local SIDEB ABC.com

zone cluster local GROUP SIDEB

element SIDEA 10.20.61.92 1719

!

zone prefix SIDEB 1.. gw-priority 10 CCMGKTRUNK_IN_2 CCMGKTRUNK_IN_3

zone prefix SIDEB 2.. gw-priority 10 CCMGKTRUNK_IN_3 CCMGKTRUNK_IN_2

zone prefix SIDEB 3.. gw-priority 10 CCMGKTRUNK_IN_2 CCMGKTRUNK_IN_3

zone prefix SIDEB 4.. gw-priority 10 CCMGKTRUNK_IN_2 CCMGKTRUNK_IN_3

zone prefix SIDEB 7001234567* gw-priority 10 VXMLB1 VXMLA1

zone prefix SIDEB 88.. gw-priority 10 CVP1 CVP2

zone prefix SIDEB 9* gw-priority 10 VXMLB1 VXMLA1

gw-type-prefix 2#* default-technology

lrq forward-queries

timer cluster-element announce 10

no shutdown

I have device target and Labels configured properly.

geoff@hp.com Sun, 05/10/2009 - 04:09

I don't think those debugs are useful.

The agent is chosen by the Call Router (just went available or LAA) and the Call Router returns the label of the extension to the routing client - which is CVP.

CVP asks the gatekeeper and the gatekeeper tells CVP to tell CUCM about it. You have a gatekeeper controlled trunk from CUCM to CVP, so the signalling goes that way to CUCM.

The precall gets to the agent desktop, it replies asking for the call to be sent, but the call never gets there. The PIM responds to the fact that the call did not get there. Two errors in a row and the agent is made not ready.

You probably have all the CVP, GW and GK config correct - so look at the CUCM and see what is going on. Turn up trace on the CTI Manager (the other end of the JTAPI gateway) and trace the call by the agent extension. Look for the error. If you don't see any action at all, go over the GW/GK settings again.

Regards,

Geoff

sandeep pokhriyal Sun, 05/10/2009 - 06:09

Hi Geoff,

thanks for your reply.

One thing what i am not able to see in gatekeeper debug is the call from CVP.

The logs in CVP are showing some exceptions.

The CVP is registered to Gatekeeper and it should send call to it.

sandeep pokhriyal Sun, 05/10/2009 - 05:57

Error in CVP logs.

2569: 10.20.20.60: May 10 2009 11:06:52.744 +0300: %CVP_7_0_IVR-3-CALL_ERROR: Removing CALLGUID: 8053BE120C8C61A01C0008020A142504 DNIS=8881 due to exception in CallNewHandler. (Client: 10.20.20.60) Unexpected exception for new call request. Exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 4 HTTP req: { CALL_ID=8053BE120C8C61A01C0008020A142504, CLIENT_TYPE=ISN, MSG_TYPE=CALL_NEW, CALL_DNIS=8881, CALL_ANI=201, ERROR_CODE=NONE(0) } [id:3023]

2577: 10.20.20.60: May 10 2009 11:07:30.667 +0300: %CVP_7_0_IVR-3-UNKNOWN_EXCEPTION: CALLGUID=4F3E13D93C7111DE82AB0022915807BE Processing exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 4 (ConnectTask.runTask)

java.lang.StringIndexOutOfBoundsException: String index out of range: 4

at java.lang.String.substring(String.java:1765)

at com.cisco.cvp.ivr.ConnectTask.generateResponse(ConnectTask.java:129)

at com.cisco.cvp.ivr.CallTask.runTask(CallTask.java:263)

at com.cisco.cvp.ivr.CallTask.run(CallTask.java:313)

at com.cisco.ccbu.infra.threads.CCBURunnable.run(CCBURunnable.java:35)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

[id:3012]

2578: 10.20.20.60: May 10 2009 11:07:30.667 +0300: %CVP_7_0_IVR-3-CALL_ERROR: Removing CALLGUID: 4F3E13D93C7111DE82AB0022915807BE DNIS=8881 due to exception in CallNewHandler. (Client: 10.20.20.60) Unexpected exception for new call request. Exception: java.lang.StringIndexOutOfBoundsException: String index out of range: 4 HTTP req: { CALL_ID=4F3E13D93C7111DE82AB0022915807BE, CLIENT_TYPE=ISN, MSG_TYPE=CALL_NEW, CALL_DNIS=8881, CALL_ANI=5577630, ERROR_CODE=NONE(0) } [id:3023]

2588: 10.20.20.60: May 10 2009 11:15:22.097 +0300: %CVP_7_0_IVR-3-CALL_ERROR: CALLGUID=8072F53D028E61A001000A030A141E3C DNIS=70012345671025 Media Fetch Error for URL=http://media/en-us/app_group/queue_music1.wav (Client: 10.20.20.60) [id:3023]

2589: 10.20.20.60: May 10 2009 11:15:22.097 +0300: %CVP_7_0_IVR-3-CALL_ERROR: RunScript Error from 10.20.20.60 [MEDIA_FILE_NOT_FOUND(9)] CALLGUID: 8072F53D028E61A001000A030A141E3C DNIS=70012345671025 {VRUScriptName: 'PM,queue_music1.wav' ConfigParam: 'N'} [id:3023]

2616: 10.20.20.60: May 10 2009 11:15:45.926 +0300: %CVP_7_0_IVR-3-CALL_ERROR: CALLGUID=0025DC4C1B8E61A004000D030A14160C DNIS=70012345671026 Media Fetch Error for URL=http://media/en-us/app_group/queue_music1.wav (Client: 10.20.20.60) [id:3023]

2617: 10.20.20.60: May 10 2009 11:15:45.926 +0300: %CVP_7_0_IVR-3-CALL_ERROR: RunScript Error from 10.20.20.60 [MEDIA_FILE_NOT_FOUND(9)] CALLGUID: 0025DC4C1B8E61A004000D030A14160C DNIS=70012345671026 {VRUScriptName: 'PM,queue_music1.wav' ConfigParam: 'N'} [id:3023]

2641: 10.20.20.60: May 10 2009 11:16:35.489 +0300: %CVP_7_0_IVR-3-CALL_ERROR: CALLGUID=80F3106A4C8E61A0030016020A14160B DNIS=70012345671027 Media Fetch Error for URL=http://media/en-us/app_group/queue_music1.wav (Client: 10.20.20.60) [id:3023]

2642: 10.20.20.60: May 10 2009 11:16:35.489 +0300: %CVP_7_0_IVR-3-CALL_ERROR: RunScript Error from 10.20.20.60 [MEDIA_FILE_NOT_FOUND(9)] CALLGUID: 80F3106A4C8E61A0030016020A14160B DNIS=70012345671027 {VRUScriptName: 'PM,queue_music1.wav' ConfigParam: 'N'} [id:3023]

2696: 10.20.20.60: May 10 2009 11:20:05.931 +0300: %CVP_7_0_IVR-3-CALL_ERROR: CALLGUID=00FFD4E71F8F61A00A0013030A141E3C DNIS=70012345671031 Media Fetch Error for URL=http://media/en-us/app_group/queue_music1.wav (Client: 10.20.20.60) [id:3023]

geoff@hp.com Sun, 05/10/2009 - 08:11

Sandeep,

I do not want to be caught out again by commenting on CVP problems without knowing exactly what the set up is. Let's forget about getting the call to an agent for a second.

Consider a simple ICM script with a "Send To VRU" node followed by a Run External Script using your Play Media microapp ("PM,queue_music1.wav"), then a Release.

1. Is your call coming in from the PSTN or an FXS port?

2. Does it successfully play this message to the caller?

I would guess by the trace above the answer is no. Let's get that part working, then we can look at a modification - adding your Queue to SG node.

Regards,

Geoff

sandeep pokhriyal Sun, 05/10/2009 - 08:17

Geoff,

1) The call is coming from PSTN.

2) The script is played to caller. If i put any message it is playing that. The call is going to queue also if no agent is available but as soon as i make agent ready this errors come.

Thanks,

Sandeep

geoff@hp.com Sun, 05/10/2009 - 11:45

So that error we see in your log is when you queue it to an available agent?

Simplify the script - after playing the message just return the label (on the CVP RC) of the agent extension. The system should try to send the call there.

Regards,

Geoff

vettiyattil.par... Sun, 05/10/2009 - 22:31

Check your all IPCC Phones whether they are configured properly. Specially check whether each and every IPCC phone is configured under device target or not.

Whenever you have a phone not configured in device target we have this kind of issues.

I hope this might be the issue in your case also.

Do the testing and let me know.

geoff@hp.com Mon, 05/11/2009 - 04:28

No. That's not the problem - please read the thread again.

The agent is being reserved - the original poster says so. What does this mean?

It means that the Call Router has chosen the agent (LAA, just became available) and through the PG, sends the reservation request.

This means the device target is correct and that the label on the routing client is correct.

Most CVP problems we see here are not this. UCCE novices make this mistake - but in general, those tackling CVP have a bit of ICM experience and don't make this mistake.

They may make the minor mistake of adding the label on the CUCM RC when it's not required, but I see very experienced people doing that too. They had to do it with CUCM and IP IVR, so it seems strange not to add it when doing CVP.

Regards,

Geoff

sandeep pokhriyal Mon, 05/11/2009 - 06:15

Hi,

We sorted out the problem finally the call is landing on agent phone.

The issue was the extension length.

I changed the extension length to 4 digits and it works fine.

Still i have no idea why this happens we are investigating the matter as i post this.

Thanking all for your esteemed support.

sandeep pokhriyal Mon, 05/11/2009 - 07:47

Hi,

If i change the extension length to 3 in PG and login to 3digit extension the same problem reoccurs.

Donno if this is a bug with CVP or ICM.

we have latest patches also installed.

Regards,

Sandeep

geoff@hp.com Mon, 05/11/2009 - 11:27

Sandeep, not to worry. No one in their right mind would use three digit extensions with CVP.

I also think 4 is too small (we have been caught out when customers insisted on 4 digit extensions, despite our objections).

I want at least 5 for single sites.

For multi-site deployments within a country, I think you need 7 or 8.

For international deployments, we use 8 or 9.

Regards,

Geoff

sandeep pokhriyal Mon, 05/11/2009 - 21:36

thanks geoff,

I would definitely keep this in mind for next designs but i don't understand why it doesn't work with 3 digits.

Our setup is having 200-250 agents and can go maximum to 350 in coming 5 years.

As the customer was already using other product he wanted to keep the agent extensions same.

We are able to see some errors in CVP i guess this thing is hard-coded.

geoff@hp.com Tue, 05/12/2009 - 00:34

Sandeep,

"As the customer was already using other product he wanted to keep the agent extensions same."

That's often the reason, but it does not work out very well to have such a limited dial plan.

If all agents have to enter (say) "74xxx" where xxx is the old three digit extension, then they don't really have to remember anything special, as the prefix is always "74".

But now you have a 5 digit dial plan, and that's going to be much more successful and expandable.

Regards,

Geoff

Actions

This Discussion