CVP 4.0(2) Comprehensive bootstrap.vxml fails on Send to VRU

Unanswered Question
Dec 28th, 2007

Hello all and Happy holidays

We're implementing CVP 4.0(2) comprehensive model and we're having some issues with Send to VRU leg and bootstrap.vxml. Specifically Calls are being aborted on send to VRU on ICM. We have narrowed down the issue to the gateway and this is the error we're getting with "debug voip app vxml all"

Dec 29 06:18:26.278: //105/248D259D61F5/VXML:/vxml_nmtokens_proc:

name=MSG_TYPE

name=CALL_DNIS

name=CALL_ANI

name=ERROR_CODE

name=RECOVERY_VXML

name=CLIENT_TYPE

name=CALL_ID

name=SIP_CALL_ID

name=CALL_UUI

Dec 29 06:18:26.278: //105/248D259D61F5/VXML:/vxml_jse_global_switch:

switch to scope(anonymous)

Dec 29 06:18:26.278: //105/248D259D61F5/VXML:/vxml_uri_parse:

CALL_ERROR; flash:bootstrap.vxml

at line 124: invalid url http://10.27.1.62:8000:8443/cvp/VBServlet

I suspected that bootstrap.vxml was being called directly and so the variabls are not setup properly but "show call application voice summary"

returns:

new-call Vxml Script flash:bootstrap.vxml

vru_leg Tcl Script flash:bootstrap.tcl

and

my running config has :

dial-peer voice 811 voip

description For incoming Leg (Type 10 label and Correlation ID)

translation-profile incoming block

service vru_leg

voice-class codec 1

incoming called-number 811T

dtmf-relay rtp-nte h245-signal h245-alphanumeric

no vad

I very Much appreciate if someone can help me with this.

Regards,

Farhang Farid

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
farhang.farid Sat, 12/29/2007 - 12:15

Never mind the question, I realized the problem had to with an older version of boostrap.tcl I tried rewriting the file on the flash but that didnt resolved the problem. It turned out that i actually had to rebuild the service associated to this file

No worries. This just happened to me too!

What I had done was installed the 4.0(1) product and on this CD there is an additional directory called "GWDownloads", so I also copied that to the OAMP machine. I used the slow and clunky Ops Console method of pushing the files to the gateway (rather than TFTP) but chose them from this directory instead of from Cisco\CVP\OPSConsoleServer\GWDownloads where they had been updated by the 4.0(2) patch.

Had fun debugging but I now have little hair left. Wish I had seen your post first!

Regards,

Geoff

Sheraz Saeed Lodhi Fri, 08/07/2009 - 10:53

Hi all,

I am facing the issue "Send To VRU" node gets abort in ICM script. I am using cvp7 with CM7. My call originator is Call manager i am dialing the script from my IP phone which is registered with CM.ICM label is 45199T. logs are attached. usng CVP SIP service with local routing.

Attachment: 

For CUCM originated calls, either a call instigated from an IP phone to a number that is a true CUCM route point, or from CTIOS/CAD to a DNP entry that "dummies" a route request that runs an ICM script, and whether this is in the context of a SIP warm transfer or a stand-alone call, there are a number of items I consider as a check list to make this work.

See if this makes sense to you and check that you have all of this set up correctly. Substitute your own NVRU labels and so on.

I have this working from CAD using a DNP, and from an IP phone using a CUCM route point. Both work correctly. This is not an easy thing to configure, and there are a number of things that can go wrong. Here is a check list that may help you get this working.

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 8222222222.

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

7. Dialed Number List - dialed number for the incoming call associated with the customer instance. This dialed number is on the CVP PIM Routing Client. This DN is associated with a call type which is then mapped to the initial script.

8. 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 3151 is associated with a call type which is mapped to the transfer script.

9. DNP. The number transferred to from CAD is 3141 which is a pattern in the DNP that maps to the Dialed Number 3151 with a post route to CUCM PIM Routing Client. The DNP Type is "PBX" - and PBX is set up in the Agent Desk Settings

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

11. When the second call is placed for the warm transfer, the label defined on the CUCM RC plus the correlation ID will be sent back via EAPIM/JGW to CUCM (for example, if the label is 8222222222, with a correlation ID it could be 822222222212345) since the call originated from the CUCM RC and since the NetworkTransferPreferred check box is not checked.

12. A route pattern 8222222222! in CUCM sends the call down a SIP trunk to CUPS.

13. CUPS has a static route on 8222222222* to send the call to the CVP Call Server.

14. CUPS has a static route on 8111111111* to get the IP call to the gateway. Note that in a branch office deployment, TDM calls into the gateway use "Send to Originator" pattern in the Call Server to force the transfer label back to the voice gateway; so this pattern in CUPS is ONLY used by VoIP calls.

15. MTP is checked for this SIP trunk (I want to hand off the call to the queue)

16. Check that the MTPs are in the same device pool as the SIP trunk that needs MTPs.

17. 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.

18. For the device targets, you need a label on the CVP RC, but you do not need one on the CUCM RC, so do not add one.

Now that we have 12.4(15)T8 there is no longer any need to have "MTP required" on the SIP trunk to CUPS.

Regards,

Geoff

Actions

This Discussion