Created by: MIKE KEUTZER on 13-12-2008 01:18:11 AM I am the CVP training instructor for Sunset Learning Institute. Our labs for CVP include using the ICM Dialed Number Plan for subsequent transfers (as well as using CTI Route Points). This lab continues to kick-my-rear, as sometimes it works and sometimes it does not… I thought I had things nailed down 2 weeks ago by upgrading ICM and CTI OS (including desktop) from 7.2(4) to 7.2(6). It worked then, but not this week…
I’m running CVP 7 with update 7.0.2_38 and UCM 6.0.1. My gateways are running 12.4(15).T3… I’m initially routing PSTN (or IP) originated calls into a “main” script which uses a “Queue to SG” node to select an agent (this works fine). The agent (from the desktop calls a dialed number plan of 3141, which aliases to a UnifiedCM dialed number of 3151 and the type is set to PBX, which matches my Agent Desk Settings. This aliased number is used to transfer to another ICM “transfer” script, and you can see the calls getting to the script – but failing on the Send To VRU node. (This transfer script works just fine when you send and initial CVP call thru it) The Agent Desktop (CTI OS) reports a “IPCC Error 10144”. I know that the “Network Transfer Enabled” ECC variable can cause issues – not using that in the main script or subsequent script (but have tried it with it in as well…).
H.323, SIP with and without Proxy all produce the same result… CTI Route Point transfer labs (which use a different number) all work as advertised as do all other labs.
Not to belabor the point - I’ve successfully made this work previously (same equipment/code/etc…), but it seems to be a continual mystery when I do… Thanks for any light you can help shed on my dilemma!
Subject: Re: ICM Dialed Number Plan transfers with CVP Replied by: GEOFFREY THOMPSON on 13-12-2008 04:15:13 AM 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
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.
Subject: Re: ICM Dialed Number Plan transfers with CVP Replied by: MIKE KEUTZER on 08-01-2009 05:21:30 AM Thanks for the information, Geoff. Most of my 947 steps were configured correctly, but I made 2 critical errors:
1.) I did not associate the transfer (aliased) DN to my customer. I believe this to be the root of my intermittent success.
2.) In my CTI Route Point labs, I correctly configure the Label associated with Unified CM (also configured as a Route Pattern in Unified CM), but the DN Plan lab does not ask the student to do this. Depending on the order of labs accomplished would certainly have an impact on things. Was I thinking that anything could possibly happen without some kind of a pattern? Perhaps I was thinking that a little magic could actually happen, but I see the errors in my ways at this point.
A few follow on points of interest:
Using the "Set Transfer Enabled" node in either the lead, or transfer script (or both, or none) did not seem to impact the ability to transfer the call...
Transferring the original call consumed an additional CVP port...
Thanks again, Mike
Subject: RE: Re: ICM Dialed Number Plan transfers with CVP Replied by: Prasanth Kumar B on 01-07-2010 01:35:31 PM HI, I have implemented a new consult transfer setup. The Call Flow: Call - > GW ->CVP ->ICM -> VXML -> Agent [initiates consult Xfer] - CUCM - ICM returns VRU label - CUCM - H323 trunk - CVP The call fails in consult xfer leg at the send to VRU node. The label returned to CUCM does not have the correlationID. It just sends back the 10 digit label. Due to which the it fails on send to VRU. Can someone help me , why is'nt ICM appending correlation ID. When will this happen? Thanks Prasanth
Subject: RE: Re: ICM Dialed Number Plan transfers with CVP Replied by: Bill Webb on 01-07-2010 04:12:52 PM I would check the items earlier in this thread, namely: 1. Make sure there is NO Network VRU defined for the UCM Peripheral in PG Explorer on the Advanced tab. 2. Make sure "Network Transfer Preferred" is NOT checked on EITHER the UCM or CVP Peripherals in PG Explorer on the Routing Client tab. Also, for Mike K's benefit - I don't recall all of the exact details of when deviations would apply (I can look them up if you want - shoot me an email - all results of tedious testing and verification with Cisco at one of our customers), but basically, any "standard" CVP installation with UCCE does not need the "NetworkTransferEnabled" flag set in the scripts, and "Network Transfer Preferred" should be unchecked for all Peripherals. - Bill
Subject: RE: Re: ICM Dialed Number Plan transfers with CVP Replied by: Prasanth Kumar B on 04-07-2010 07:42:42 PM Hi Bill, You were right ..Bang on spot. The CUCM PG had a default VRU set. Removed this config and now I can see correlationID appended. But now I have diffrent problem. :-) The consult xfer lands on 2nd Agent and answers the call. But when Agent 1 tries to complete consult transfer, the call fails. This is a H323 call flow. Any idea what could be wrong. Thanks for the reply. -Prasanth
Subject: RE: Re: ICM Dialed Number Plan transfers with CVP Replied by: Bill Webb on 07-07-2010 07:39:31 AM This is another common issue, so there's a few possibilities. I'll list the setup we normally use (and it is based off Cisco docs): 1. H.225 Gatekeeper-Controlled Trunk configured in UCM for Gatekeeper. CVP Call Servers should NOT be configured as gateways, and Trunk should NOT have "MTP Required" checked. 2. In UCM Clusterwide Parameters, under H.323, make sure "Allow Anonymous Access" is set to "True", and that the "Default Device on Port 1720" (that's not the exact verbiage) is left blank (the default). 3. If you are using 79x1 or newer model phones, and IOS release older than 12.4(20)T, then you need to disable "Advertise G.722 Codec" on the phones, as the older IOS doesn't support it for transfers. 4. Make sure you do not have any other codec issue (no codec change) between the 1st Agent Phone, the gateway, and the 2nd Agent Phone. That should be a good start...! ;-) - Bill
Subject: RE: Re: ICM Dialed Number Plan transfers with CVP Replied by: Prasanth Kumar B on 07-07-2010 03:39:59 PM Hi Bill, Wow . thats a nice check list. Luckly I passed on all the items. Looks like this to be an issue with the size of the label [xferlabel + correlation ID]. So I have to upgrade PG to latest version and try my luck. Will keeep you posted Thanks Prasanth
I'm in need of an application that allows facility techs (who do the bulk of the Phone Moves, adds, and changes) on a daily basis to verify that the phone is in the correct ERL, and correct VLAN. What I envision is a CCX application that pulls the CE...
Hi All, This is basically an offshoot of post https://community.cisco.com/t5/management/python-with-axl-updatephone-fail/m-p/4031354/highlight/false#M3313. I took the excellent suggestions made by npetrele, and reviewed the demo at htt...