CVP - Comprehensive call flow model with SIP

[rajasekarvs]

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

[skatzman]

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]

Hi Seth,

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

Raj

[rajasekarvs]

Please find the logs from call server,router and VRU PIM as attached and advise.

Raj

[geoff]

Why is the "new call" showing up on Trunk Group 200? That's normally used for trans routes. I would have expected this to be on trunk group 100.

Regards,

Geoff

[rajasekarvs]

Hi ,

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

Raj

[rajasekarvs]

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

[geoff]

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]

Hi Geoff,

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

Gokul

[geoff · Accepted solution]

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]

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

[geoff]

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]

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:42743436666@10.11.0.41&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]

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:42743436666@10.11.0.41, 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]

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