I have a CVP 7.0(1) set up with warm transfers activated at the CTIOS desktop using the DNP (Dialed Number Plan) so that the agent starting the transfer can either wait for the second agent to answer, or dump the call off into the queue and go onto another call. Works fine if there is one combined gateway (Ingress/VXML) but has issues when there are more than one of these, or when there are split ingress and VXML gateways.
I implemented SIP.sigdigits to take care of the split gateways, but it broke the warm transfer.
Because sigdigits is set (in my case, I used 3), when the IVR transfer label arrives at the Call Server (the label on the NVRU for the CUCM routing client), it strips off the first three digits and and cannot locate the correlation ID.
The number of digits in the label before the correlation ID is the typical value of 10 (say 8111111111 for the NVRU label on the CVP RC, and 8222222222 for the NVRU label on the CUCM RC).
If I change the 8222222222 to (say) 8888222222222 and change the static route in the SIP proxy that finds a Call Server to match, perhaps it will work.
Has anyone successfully done this?
(By the way, 12.4(15)T8 has fixed the issue where the SIP trunk from CUCM to CUPS required MTPs in order to dump the call off in the queue.)
My idea worked. I changed three things: the NVRU label on the CUCM RC, the route pattern in CUCM that sends the call down the SIP trunk to CUPS, and the static route in the SIP proxy to find a Call Server. Amazing!
Mmm, it's not quite as good as I expected. I changed the prefix for these three items to be 666, to make it different from the 333 I was using in the gateway - but it broke. I have a feeling that this will not work as I had hoped for - which was to be able to have a transfer go back to the same VXML gateway as the incoming call.
I am doing exactly the same thing at one of my customer, who has ~100 locations where each site will have it's own vxml gw.
The bigger challenge I found was controlling IP initiated calls from CM as I now need to prefix the "site code" to each call, but this is the only way I was able to control which VXML GW is engaged on IP initiated calls.
Thanks for your reply.
I have a customer who is bringing up independent branch offices (2 in the US and more than a dozen in EU) and I also need to deal with CUCM initiated calls in a similar way.
If a non-agent in (say) the Italy call center (2 VXML gateways, incoming PSTN trunks) wants to transfer an outside call (or even generate the call) to an internal route point in CUCM, I want the call to queue on the local VXML gateway.
My design uses 8 digit numbers for contact center agents and for internal route points, and the first three digits are the site code, but what to do next?
This CUCM RP is a DN so it runs a script which first has a "Send To VRU", which returns the NVRU label on the CUCM RC - but there is just one of these. It is a route pattern on the trunk to CUPS (SIP Proxy), and the Call Server sends it back up with the correlation ID, so the script resumes. The next node (either a Run Ext Script or Queue to SG) does an implicit Send to VRU which sends the call to a gateway. Again, just one NVRU label on the CVP RC, so it picks a gateway listed in the static routes of the Proxy.
I'm struggling to see how you can direct this to a specific gateway.
Can you give me a hint please mate.
The way I do it is not by route points but by having route patterns pointing to the SIP Proxy, the call flow looks something like this:
1. IP Phone dials 5000, which matches local route pattern
2. 8001 is prefixed to the call and sent to CUPS Proxy server
3. Proxy server is configured with route 80015000 pointing to CVP servers
4. CVP strips 4 digits and delivers 5000 to ICM
5. ICM invokes script and send call to VRU via i.e 999999999 label
6. CVP prefixes stripped digits in front of the label, as a result the VRU label looks something like 80019999999999
7. CUPS Proxy has static route of 80019* that point to the desired vxml gw
8. Bootstrap file is invoked by the dial peer and prompts are played
Forgot to mention that 001 represents the site code, and 8 is used as on-net access code, basically the idea here is to assign unique site code to each location.
Thanks. I understand.
That method (route pattern) will work for IP phone generated calls, but will not work for warm transfers when the customer is already on the phone with an agent, for there we need a route point in ICM for call continuity.
I suppose I could have two sets of "internal route points" - one that is called by an IP phone where we have no need to preserve call variables and can view it as a new call, and a parallel set for warm transfers (using DNP in ICM to invoke the route request). The customer won't like this complexity, although the DNP patterns are called out of the CAD phone book and are selected by name. That may fly.
That would reduce the scope of the problem - those CUCM generated calls would use the local VXML gateway; but the warm transfers still bother me.
I currently only have one ingress gateway and one VXML gateway set up in the development system, so I cannot be certain that if I have two (say one prefixes 666 and one prefixes 333) that a warm transfer will queue on the VXML gateway at the site. It may just work - I'll have to test it.
Not sure if it is related or not. Warm transfers do not work with IP-originated calls if codec is G.729 in CUCM 6.x.
This limitation is fixed in CUCM 7.x.
Enhancement request has been filed but I heard 6.x development has been closed.
The workaround is to use G.711 or upgrade to 7.x.
Interesting, I have CM 7 and I am noticing that on warm transfers the prompts sounds horrible I mean un-listenable when codec g729 is used and allowed on the vxml GW. Any trick to it?