CVP call server error

[Hossain Ahmed Ashfaque]

Hi,

I am facing issue with my cvp call server. Whenever I call the cti route point using my IPC it gives busy tone. Its not even playing the cvp error messege. The configuration of the VG is attached.

IPC= 1011, CTI route point=6322337, Label on Network VRU (type 10) =1000003 with CUCM routing client

The logs of the call server is as below

193: 172.21.152.9: Feb 03 2011 16:01:58.625 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=DATAI.0} CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND]: Display Name ["Kenon Woo CIPC"] Is Using Survivability [false] CallServer build CVP_8_0_1_0_0_0_1440 
194: 172.21.152.9: Feb 03 2011 16:01:58.625 +0800: %CVP_8_0_SIP-7-PARAM:  {Thrd=DATAI.0} CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND]: ReqURI (DN) sip:10000036322337@172.21.152.9:5060 FromURI sip:1011@172.21.152.5 Video:false m_needs_postcallsurvey:false 
195: 172.21.152.9: Feb 03 2011 16:01:58.625 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=DATAI.0} NEW CALL with guid=EA8AC3611000012D504332B053EA67F7 legid=46f49180-d4a15ff8-44-59815ac dn=10000036322337 ani=1011 uui=null calldate=Thu Feb 03 16:01:58 GMT+08:00 2011 video=false cachecallcontext = false is_postcallsurvey = false RouterCallKey = null RouterCallKeyDay = null RouterCallKeySequenceNumber = null 
196: 172.21.152.9: Feb 03 2011 16:01:58.625 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=DATAI.0} Sending msg:>>HEADERS: (JMSType)=MsgBus:NEW_CALL (JMSDestination)=Topic(CVP.SIP.CC.REQ) (JMSTimestamp)=1296720118625 >>BODY: replyto=true callguid=EA8AC3611000012D504332B053EA67F7 ani=1011 dnis=10000036322337 timezone=GMT+08:00 version=CVP_8_0 pstntrkgrpsrcip=172.21.152.5 calldate=Thu Feb 03 16:01:58 GMT+08:00 2011 calltypeid=4 localOffset=480 calllegid=46f49180-d4a15ff8-44-59815ac  >>STATE: isTabular=false isWriteable=true cursor=-1 
174: 172.21.152.9: Feb 03 2011 16:01:58.640 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-115-ICM-2} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = -1 [null] - Processing ,, [MsgBus:NEW_CALL],   ssId=SYS_SIP1,   mediaType=,   location=,   locationpkid=,   locationsiteid=,   srcaddr=172.21.152.5,   pstntrunkgroupid=172.21.152.5 ,   pstntrunkgroupchannelnum=2147483647,   sipheader=,   rckey=,   rcday=,   rcseq=,   uui=,   CallContext:,     user.media.id: EA8AC3611000012D504332B053EA67F7,, LEGID = null, DNIS = -1, ANI = -1 
175: 172.21.152.9: Feb 03 2011 16:01:58.640 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-115-ICM-2} CALLGUID = EA8AC3611000012D504332B053EA67F7 - Correlation ID routed call 
176: 172.21.152.9: Feb 03 2011 16:01:58.640 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-115-ICM-2} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Publishing ,, [ICM_REQUEST_INSTRUCTION],   dialogueId=1,   sendSeqNo=1,   trunkGroupId=200,   trunkNumber=0,   serviceId=2,   uui=,   correlationId=6322337,   location=,   locationpkid=,   pstntrunkgroupid=172.21.152.5 ,   pstntrunkgroupchannelnum=2147483647,   sipheader=,, LEGID = 46f49180-d4a15ff8-44-59815ac, DNIS = 10000036322337, ANI = 1011 
177: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-116-ICM-3} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Processing ,, [ICM_DIALOGUE_FAILURE_EVENT],   dialogueId=1,   sendSeqNo=1,   errorCode = E_UNSPECIFIED_FAILURE,, LEGID = 46f49180-d4a15ff8-44-59815ac, DNIS = 10000036322337, ANI = 1011 
178: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-116-ICM-3} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Publishing ,, [MsgBus:DIALOGUE_FAILURE],   ssId=SYS_SIP1,   errorCode=E_UNSPECIFIED_FAILURE,, LEGID = 46f49180-d4a15ff8-44-59815ac, DNIS = 10000036322337, ANI = 1011 
197: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND] - DIALOGUE_FAILURE from ICM Router sends 404 rejection to call. errorcode=15 [id:5004]
198: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=pool-1-thread-117-SIP-583} Sending BUS MSG:>>HEADERS: (JMSType)=MsgBus:CALL_STATE_EVENT (JMSDestination)=Topic(CVP.SIP.CC.EVENT) (JMSTimestamp)=1296720118656 >>BODY: callguid=EA8AC3611000012D504332B053EA67F7 RouterCallKeySent=false causecode=1 timezone=GMT+08:00 version=CVP_8_0 calldate=Thu Feb 03 16:01:58 GMT+08:00 2011 localOffset=480 eventid=6 calllegid=46f49180-d4a15ff8-44-59815ac  >>STATE: isTabular=false isWriteable=true cursor=-1 
199: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=pool-1-thread-117-SIP-583} CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND] DURATION (msecs) = 31 - HANGUP with Call History 
200: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND] - ABNORMALLY ENDING - SIP code [404], Reason Hdr [SIP;cause=404] Not Found, GW call using SURV TCL flag [false], NON NORMAL flag [true], USE ERROR REFER flag [true] with AGE (msecs) 31 and Call History :  [id:5004]
201: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=pool-1-thread-117-SIP-583} Matched 92929292 to 172.21.152.23 
202: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=pool-1-thread-117-SIP-583} Using Local Static Route for sip:92929292@172.21.152.23 
203: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_SIP-7-CALL:  {Thrd=pool-1-thread-117-SIP-583} CALLGUID = EA8AC3611000012D504332B053EA67F7 LEGID = 46f49180-d4a15ff8-44-59815ac - [INBOUND] REDIRECTING with 302 response. 
179: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-118-ICM-4} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Processing ,, [MsgBus:CALL_STATE_EVENT],   ssId=SYS_SIP1,   eventId=DISCONNECT,   causeCode=NORMAL_COMPLETION,, LEGID = 46f49180-d4a15ff8-44-59815ac, DNIS = 10000036322337, ANI = 1011 
180: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-118-ICM-4} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Publishing ,, [ICM_EVENT_REPORT],   dialogueId=1,   sendSeqNo=2,   eventId=DISCONNECT,   causeCode=NORMAL_COMPLETION,, LEGID = 46f49180-d4a15ff8-44-59815ac, DNIS = 10000036322337, ANI = 1011 
181: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-118-ICM-4} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Deleted dialogue. Duration: 0 hrs, 0 mins, 0 secs, 16 msecs 
182: 172.21.152.9: Feb 03 2011 16:01:58.656 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=pool-1-thread-118-ICM-4} CALLGUID = EA8AC3611000012D504332B053EA67F7 - Deleted call.  Duration: 0 hrs, 0 mins, 0 secs, 16 msecs 
183: 172.21.152.9: Feb 03 2011 16:02:11.625 +0800: %CVP_8_0_ICM-7-CALL:  {Thrd=ICM Garbage Collector} CALLGUID = EA8AC3611000012D504332B053EA67F7, DLGID = 1 [SIP_LEG_PRERTE_CORRID] - Purged dialogue.  
830: 172.21.152.9: Feb 03 2011 16:06:50.750 +0800: %CVP_8_0_Infrastructure-6-STATS: %[stats_maps_logged={STATS_RT_JVM_TOTAL_MEM=1065484288, STATS_RT_JVM_CURRENT_MEM_USAGE=71541696, STATS_RT_JVM_THREADS_IN_USE=627, STATS_RT_JVM_AVAIL_MEM=993942592, STATS_RT_JVM_PEAK_MEM_USAGE=98248320, STATS_RT_JVM_UPTIME=13201547, STATS_RT_JVM_PEAK_THREADS=627}][stats_obj_id=JVMStats][stats_obj_type=real time]: stats object statistics [id:9019]
831: 172.21.152.9: Feb 03 2011 16:06:50.750 +0800: %CVP_8_0_Infrastructure-6-STATS: %[stats_maps_logged=n/a][stats_obj_id=JVMStats][stats_obj_type=interval]: stats object statistics [id:9019]

Thanks and Regards,

Ashfaque

[geoff]

There is a SIP 404 error. CVP does not know where to send the call.

Regards,

Geoff

[Hossain Ahmed Ashfaque]

Hi Geoff,

Thanks for the reply. I have changed the configuration and now the calls are not hitting the CVP call server. I am using ICM, CVP and CUCM version 8. When I am calling CTI Route point I am getting busy ringtone. From the ICM script I can see that calls are failing on SendtoVRU node.

Overview of the configuration is given below:
1. All the required pims are active and also cvp call and vxml server are up.
2. Configured as PG Generic. In PG explorer network transfer is checked. and in the advanced tab Network VRU is selected.
3. On network VRU a label (1000003.CUCMPG.RC) is created. On Call Manager SIP trunk is created for CVP. A route pattern (1000003!)is created and assign with the SIP trunk.
4. A CTI route point (6322337) is created in Call Manager for this Dial number script is created on ICM.

Thanks and Regards,

Ashfaque

[geoff]

We have discussed this a number of times on the forum. You should search for posts using the keywords "CVP warm transfer" because that's what we have normally discussed this under - but all CM originated calls fall under this.

I have posted a step by step check list for making this work. If you don't mind, search for my most recent post on CVP warm transfer with that check list and go down the list and compare what I wrote to what you have on your setup. I bet you will find the configuration error.

Please post back when you find the bug - it will assist others.

Regards,

Geoff

[Hossain Ahmed Ashfaque]

Hi Geoff,

Thanks for the advice. I used the same method which was described there. Below are the steps.

1. PG Explorer - CUCM PIM Routing Client - Network Transfer Preferred not checked

2. PG Explorer - CVP PIM Routing Client - Network Transfer Preferred not checked

3. PG Explorer - CUCM PIM Advanced - Network VRU - NONE

4. PG Explorer - CVP PIM Advanced - Network VRU - Type 10

5. NVRU Explorer - Type 10 Network VRU, label for the CUCM routing client associated with the customer instance. Let's say this is 1000003.

6. NVRU Explorer - Type 10 Network VRU, label for the CVP routing client associated with the customer instance. Let's say this is 1000001 and 1000002.

7. Dialed Number List - transfer dialed number associated with the customer instance. This dialed number is on the CUCM PIM Routing Client. The transfer dialed number 6322337 is associated with a call type which is mapped to the transfer script.

8. Agent Desk Settings - All but "Operator" are checked

9. A route pattern 1000003! in CUCM sends the call down a SIP trunk to CVP.

10. CVP has a static route on 1000003* to send the call to the CVP Call Server.

11. CVP has a static route on 10000001* and 1000002* to get the IP call to the gateway (172.21.152.23).

12. In all preliminary scripts that get the customer to the agent, set the variable Call.NetworkTransferEnabled to the value 1. This is set before the transfer is called

Perhaps I might miss something. I have attached all the configuration screenshots for reference. Please let me know if I have done some thing wrong in the configuration.

Thanks and Regards,

Ashfaque

[hiteshpa]

I am not sure what you mean by this:

"10. CVP has a static route on 1000003* to send the call to the CVP Call Server"

I believe what you may be missing is the DNIS or DNIS Range under the ICM tab on the CVP server (via OAMP). The DNIS 1000003 should be listed there for CVP to route this call to ICM. A static route won't work in this case.

Thanks,

Hitesh Patel

[geoff · Accepted solution]

OK, those steps look familiar.

5. NVRU Explorer - Type 10 Network VRU, label for the CUCM routing client associated with the customer instance. Let's say this is 1000003.
6. NVRU Explorer - Type 10 Network VRU, label for the CVP routing client associated with the customer instance. Let's say this is 1000001 and 1000002.

Sorry, why do you have different VRU transfer labels for your two CVP Routing Clients? These should be the same. The gateway will have a dial peer to catch this and run the bootstrap, so it would be looking for 1000001T. Everyone makes them the same (the Cisco doc uses 8111111111).

I always like to make these EXACTLY the number of digits configured in the ICM tab for Max Length of DNIS - this enables the Call Server to pull off the correlation ID. So in your case I would have 100000003 (CUCM RC) and 100000001 (all CVP RCs).

The route pattern has sent the call 1000003xxxx to CVP. It would normally start a new call, but the presence of the correlation ID means it sends the info up to the Router and it finds the script it paused at the first Send To VRU, and resumes it.

10. CVP has a static route on 1000003* to send the call to the CVP Call Server.

You don't want the above.

Now it encounters a second Sent To VRU. In this case, the RC is CVP - so it returns 1000001xxxx to CVP and there is a static route to the gateway to start the bootstrap. So you are good.

I recommend explicit Send to VRU nodes. Easier to spot the error.

Regards,

Geoff

[Hossain Ahmed Ashfaque]

Hi Geoff,

Thanks it works partially. I am still getting error message on cvp call server.

395: 172.21.152.9: Feb 08 2011 12:25:13.380 +0800: %CVP_8_0_SIP-3-SIP_CALL_ERROR:  CALLGUID = 038415D41000012E174EF0BD53EA67F7 LEGID = 8f7cc800-d501c439-65-59815ac - [INBOUND] - ABNORMALLY ENDING - SIP code [500], Reason Hdr [SIP;cause=500] Internal Server Error, GW call using SURV TCL flag [false], NON NORMAL flag [true], USE ERROR REFER flag [true] with AGE (msecs) 2000 and Call History : 10000000012092|-1; [id:5004]

and VG debug shows the below error

.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpMatchPeertype:exit@5406
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpAssociateIncomingPeerCore:
   Match Rule=DP_MATCH_INCOMING_DNIS; Called Number=10000000012090
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpMatchPeertype:
   Is Incoming=TRUE, Number Expansion=FALSE
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpMatchCore:
   Dial String=10000000012090, Expanded String=10000000012090, Calling Number=
   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/MatchNextPeer:
   Result=Success(0); Incoming Dial-peer=1000 Is Matched
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpMatchPeertype:exit@5406
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=1000
.Feb  8 04:22:26.803: //-1/547A94800000/DPM/dpAssociateIncomingPeerSPI:exit@5940

.Feb  8 04:22:26.803: %CALL_CONTROL-6-APP_NOT_FOUND: Application bootstrap in di
al-peer 1000 not found.  Handing callid 139 to the alternate app .

Also attached the VG configuration.

Thanks and Regards,

Ashfaque

[Chuck Smith]

Last line says that the application bootstrap could not be found. Did you copy the appropriate files to the flash of the gateway? Not sure if it matters but the dialpeer app name is VRU-leg and the actual app name is vru-leg. Not sure if it is case sensitive or not. Might want to try it.

[Hossain Ahmed Ashfaque]

Hi,

Actually the parser is unable handle the TCL script properly. We found that the IOS version of the VG is not completable with CVP8.0.

Thanks and Regards,

Ashfaque

[geoff]

Actually the parser is unable handle the TCL script properly. We found that the IOS version of the VG is not completable with CVP8.0.

Are you sure about that? What version of 12,4 do you have? The BOM says you should be using 12.4(24)T2 or later T, but I'd be surprised if that's your problem. I use CVP 8.x with 12.4(15)T in the lab OK.

What concerns me more is that you have mgcp controlled E1s.

controller E1 0/0/0

pri-group timeslots 1-31 service mgcp

!

controller E1 0/0/1

pri-group timeslots 1-31 service mgcp

!

controller E1 0/1/0

pri-group timeslots 1-31 service mgcp

!

controller E1 0/1/1

pri-group timeslots 1-31 service mgcp

Regards,

Geoff

[Hossain Ahmed Ashfaque]

Hi Geoff,

The problem resolved today. You are right regarding the IOS version because when we upgraded it to the newer version it did not work. Then we delete the bootstrap file from the VG and uploaded it again and this solved the problem. Which means the be the prevoius bootstrap file was corrupted.

Thanks to all for your support.

Regards,

Ashfaque

[geoff]

OK, that's good news. Thanks for posting back.

Regards,

Geoff

[ganapathi s]

Hi All,

Even am facing the same error message as mentioned below

90BB151-D20611E0-8E96B300-5F8C0247 - [INBOUND] - ABNORMALLY ENDING - SIP code [404], Reason Hdr [SIP;cause=404] Not Found, GW call using SURV TCL flag [false], NON NORMAL flag [true], USE ERROR REFER flag [true] with AGE (msecs) 368117 and Call History : 777777777716366|-1; [id:5004]

Refer failed with 503 - Service Unavailable. May be a problem with Routing Configuration or Gateway Dial-Peer. [id:5004

This error comes when an agent answers the call and it get disconnects immedtiately.

Kindly advice.

Thanks,

Gana