CVP - Comprehensive call flow model with SIP

Answered Question
Aug 31st, 2007

Hi,

We are trying to configure the CVP -Comprehensive call flow model with ICM and SIP. We are facing some problems in making the CVP call server to hit the dialed number and invoke the simple routing script. Please find the event that we are getting in the PIM OPC console as below:

15:49:54 Target assignment for CallID 20 unknown (serviceNum=2 callingIDType=70, callingDev=6553600 calledDev=5555).

Raj

I have this problem too.
0 votes

Then you need two network VRUs. A type 5 for the switch leg, where the label is not used; and a type 7 for the VRU leg, where the label is very important and the number of digits must match what is configured in AppAdmin, so that the VB knows where the correlation ID lives. See JPG.

This is explained in the CVP Config Guide.

Regards,

Geoff

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
skatzman Fri, 08/31/2007 - 05:20

Raj,

What version of CVP 4.0 are you using (CVP 4.0(1), 4.0(1)SR1, or 4.0(2))?

Do you know how far the call is making it? Does it make it to ICM and return a label? Also, it would be useful to see the CVP router logs associated with this call.

Thanks,

Seth

rajasekarvs Sat, 09/01/2007 - 21:48

Hi Seth,

Thanks for the speedy response. We are running CVP 4.0(2), ICM 7.0.

Raj

rajasekarvs Mon, 09/03/2007 - 04:58

Hi ,

We have not changed any default settings for trunk ID in the CVP call server.

Raj

rajasekarvs Mon, 09/03/2007 - 05:09

Hi,

The call is not able to get through to the VXML server , if send to VRU node being called in the ICM routing script. Rather ,if we the label node is called with the same VRU label, the call gets through to the VXML server and triggers the application. Please advise.

Raj

When the ICM routing script runs and encounters the "Send To VRU" node, that should not fail. Failure at that point means that something is not aligned correctly on the network VRU. I assume this is ICM 7.1 or greater, and you have a Type 10 NVRU.

The "Send To VRU" node should pause the routing script and cause the Call Server to use the label in the NVRU as the target, appending the correlation ID. Something like 8111111111xxxx.

The Call Server needs to ask the SIP proxy to find a voice gateway to send the call to in order to start the VRU leg. If substituting a label on the CVP routing client seems to trigger the transfer, but "Send To VRU" does not, check that the "Customer" is configured correctly.

Regards,

Geoff

gokulakrishnan.g Mon, 09/03/2007 - 09:25

Hi Geoff,

What if it's version 7.0? What is the type the Network VRU needs to be configured in?

Gokul

Correct Answer

Then you need two network VRUs. A type 5 for the switch leg, where the label is not used; and a type 7 for the VRU leg, where the label is very important and the number of digits must match what is configured in AppAdmin, so that the VB knows where the correlation ID lives. See JPG.

This is explained in the CVP Config Guide.

Regards,

Geoff

gokulakrishnan.g Tue, 09/04/2007 - 05:58

Hi Geoff,

Thanks a lot for the help. Yup we put the two network VRUs and we got the SendToVRU node working like a charm. We had some issues in our dial-pattern in the SIP Proxy. We were erroneously matching with 55556666 ( which is the label we were returning from the network VRU) but I believe when it comes for routing in the SIP Proxy the call server adds a couple of digits at the end. So we got the number as 55556666xx and the call was failing.

Once we put the appropriate route-pattern it went perfectly to the VXML Gateway.

The problem we currently we are facing is when the call hits the bootstrap.tcl and comes back to the IVR service of the Call Server. Let me take a step back and explain to you what we are trying to achieve so that you can help us better ( also it might be useful for other people who read this post in the future).

Our incoming call hits the ingress gateway and in the ingress gateway we have the dial-peer to send it to the SIP proxy. We have added the Call-Server as a SIP trunk, and for that route-pattern, the SIP proxy routes it to the Call-Server (SIP Service). It routes this call through its ICM service (via PG) to my routing script which has the following nodes ( Very simple). Start->SendtoVRU->LAA ( Yes, very simple script. We just want to see this work before we put the Start-SendToVRU->RunExtScript and then transfer to agent)

So now the call gets the Network VRU label and sends it back to the SIP service of the call server which again routes it to the SIP proxy. The VXML gateway ( in our case the same as our ingress gateway) is a SIP trunk to the SIP proxy and the Proxy sends the request to the VXML Gateway.

The dial-peer match in the VXML gateway triggers the bootstart.tcl script which we believe should instruct the IVR service in the call server to send the routerquest to ICM. We are kind of caught here. Should something be done other than the set if application commands as specified in the configuration manual. ( should the callServer ip be specified anywhere?)

Once the routerequest hits the ICM, it will start off from the SendToVRU node and go to the right node ( which is the LAA) in our case.

Is our understanding of the call flow right till now?

Since we want to use VXML Server, we don't want to do the micro-app configurations. Instead what we propose to do is have a RunExtScript Node in ICM and point it to the VXML Server application. Is this correct as well?

Thanks a lot for all the help and future help :)

Gokul

That all sounds pretty correct. You have tried to explain the call flow reasonably well. Can't see an issue though.

"should the callServer ip be specified"

It used to be, but not with the latest 4.0(2). Probably 4.0(1) as well. It used to be that you needed to have something like:

ip host isn-vxml 1.2.3.4

in your gateway IP host table, since the bootstrap was hard-coded to look precisely for "isn-vxml" to send the call to; but now, the original call server is passed in. You can see this in the trace. I had a post here on a problem with the bootstrap and you could search for that to see what my error was. It has some good descriptions.

You don't need an LAA after the "Send to VRU" - you could make it even simpler. Just have the label of an IP phone (on the correct routing client). When the script starts processing after the send to VRU it will return a label and the phone will ring.

Although you plan to use Audium, you should still do a microapp. You will need one for queuing anyway. Cisco recommend a mix of microapps and Audium - and that's what I've done in the past. Microapp for simple things like "choose a language" and (of course) waiting in queue. Audium for the complex applications.

Getting a microapp to work with the "Queue To Skill Group" playing an interruptible script is probably the next step after the label - rather than LAA.

What I can't understand from your post is - whether it's working or not. ;-)

If the call is not going to the agent in the ready state (LAA), check that you have the device target also hanging off the CVP RC (as well as the normal CCM RC). The Call Router should show an error if you forgot.

Regards,

Geoff

gokulakrishnan.g Wed, 09/05/2007 - 18:37

Geoff,

To answer your question real quick, nope it is not working :( We are stuck at the SendToVRU node. The label is returned from SendToVRU and this DN is correctly routed by our SIP Proxy to the VXML Gateway. The VXML Gateway runs the bootstrap.vxml and is supposed to send the right http request to the IVR service. We see the http request being sent in the following trace

*Sep 5 13:58:32.996: //13169//HIFS:/hifs_http_cb: hifs http callback: load of http://10.11.0.46:8000/cvp/VBServlet?MSG_TYPE=CALL_NEW&CALL_DNIS=55556666970&CALL_UUI=&CALL_ANI=sip:[email protected]&RECOVERY_VXML=flash:recovery.vxml&CLIENT_TYPE=IOS&CALL_ID=EBD48534-5AEE11DC-A93AF0C4-DABD7054&ERROR_CODE=0 failed. Status=httpc error 500=http internal service error

So we get the internal service error. On CallServer the error we see is

882: 10.11.0.46: Sep 04 2007 09:04:24.122 +0400: %CVP_4_0_SIP-3-SIP_CALL_ERROR: CALLGUID = CEE7B03A-10000114-3A4890AA-0A0B002E LEGID = fe29b280-6dc1e882-558-29000b0a - [INBOUND] - DIALOGUE_FAILURE from ICM Router sends 500 rejection to call. [id:5004]

On the the routing script on ICM, we see it getting aborted.

And yes, I took a look at the other issue you had raised in the forum, and I got the debugs turned on based on that.

The other thing that bothers me as to whether we are on the right track or not is that, I took a look at the bootstrap.tcl and it says that the CallServer ip would be determined from the App-Info header in the INVITE SIP message that comes to the VXML Gateway. I turned on the SIP logs and the INVITE that comes in does NOT have the App-Info header. Is that ok?

Gokul

gokulakrishnan.g Wed, 09/05/2007 - 21:28

Geoff,

On the call-server we got the following error as well

DF9532C0-5AE311DC-A87DF0C4-DABD7054 DNIS=55556666942 due to exception in CallNewHandler. (Client: 10.11.0.20) Received ICM DialogFailure response for new call request. DialogFailure StatusCode: 15 HTTP req: { CALL_ANI=sip:[email protected], CALL_UUI=, MSG_TYPE=CALL_NEW, ERROR_CODE=NONE(0), CLIENT_TYPE=IOS, CALL_ID=DF9532C0-5AE311DC-A87DF0C4-DABD7054, CALL_DNIS=55556666942, RECOVERY_VXML=flash:recovery.vxml } [id:3023]

rajasekarvs Mon, 09/10/2007 - 01:07

Hi Geoff,

Thanks for the valuable input and time. We have got the problem resolved after setting the maximum digits to 10 in the ICM tab of the call server and configuring the correct label as 55555555 for network VRU (VRU leg).

We are able to complete the call with the same.

Raj

Chad Stachowicz Fri, 06/13/2008 - 13:37

gokul,

Did you ever figure out the solution to this? I have been fighting with the identical error message for a day now and I am getting very frusterated :(

Thanks,

Chad

david.macias Fri, 03/27/2009 - 06:05

Chad,

We see this error every once in a while, did you ever pinpoint what it was?

thank you,

david

Chad Stachowicz Fri, 03/27/2009 - 16:46

Hey david,

I think I found out way back then it has to do with Network VRU lables. I have also seen it happen when using incorrect flow. So lets say a certain number goes ingress -> sip proxy-> ccm -> route point-> icm and using network transfer preferred. I would look deeper in this. But that particular error is shown when the sendtovru cannot complete.

Chad

david.macias Fri, 03/27/2009 - 16:48

well i think it might be close to what you saw, so I'll look into that, if you have any other info you can provide, i would greatly appreciate it.

david

mclenden Mon, 04/20/2009 - 17:19

We have seen this problem when a VXML Gateway (AS5400 in our case) has high CPU utilization. Do a "show proc cpu history' and check the last 72 hours of cpu time and see if it correlates to these errors.

Actions

This Discussion