Chris,
I have SIP.sigdigits set and I make SIP warm transfers from agents using DNP (Dialed Number Plan). I only need to keep context when agents do the transfer, so the DNP method is used. Let's say that the number called (an internal route point) to reach the routing script is 555 1234.
I also have CM generated calls working in two different ways (an IP phone cannot call a DNP).
A call can be placed from an IP phone at any site to 555 1234, which is a route point in CUCM that starts a routing script, Send to VRU kicks in and returns the transfer label on the CUCM RC.
In this method you cannot choose the gateway - the proxy will round robin between all the gateways configured as static routes in the proxy for the CVP RC transfer label.
The third method is an IP phone can call 1234 with a site-specific prefix. An agent in the St Louis branch office calls (say) 314 1234 and using sigdigits this is a route pattern in CUCM that sends the call to CVP. Now the transfer label will have the sigdigits prepended and we can make it go back to the site gateway. This is not a context-keeping transfer - CVP sees it like a new call, but I don't care. It's a way for non-agent staff to call the contact center, or transfer a customer who has called them by their DID.
I prefer the first two methods (doesn't matter which site the agent is at, they call the same number) but you need to choose which gateways to queue the transfer on. I'm thinking that in a branch office environment, a couple or gateways at the data center is the way to go.
In another deployment I am doing which uses send to originator, I'm going to do exactly that - with send to originator, the transfer label is not needed in the proxy as a static route.
Now - to your problem.
Yes - it will work. Because you have SIP.sigdigits set (let's say sigdigits = 3), you need to make the CUCM label have three extra digits because CVP will strip them off.
Let's say without sigdigits you have 8222222222 as the NVRU label on the CUCM routing client. You also have 8222222222! as a route pattern in CUCM that sends it down the SIP trunk to the proxy, and you have a static route in the proxy for 8222222222* to find a CVP Call Server. 8111111111 is the label on the NVRU for the CVP RC and 8111111111* is configured in the proxy as a static route to the gateway.
Now with sigdigits, change the label on the NVRU for the CUCM RC to (say) 5558222222222. Change the route pattern and the static route to CVP.
When the call arrives at CVP it will strip off three digits (the 555) but the rest is valid and it can find the correlation ID in the usuual way, and then find the script it has paused.
If you look at the CVP log you will probably see how it's not finding the correlation ID correctly.
Now on the way back out, CVP is going to put 555 in front of the 8111111111 so you need to have a static route to the gateway on 5558111111111* and a dial peer 5558111111111T on the gateway for the bootstrap to match this.
Once sigdigits is on, CVP is absolutely rutheless and will strip off three digits on any number that comes in, and will apply those digits to any number on the way out - transfer labels, error labels, ringtone labels. Everything.
Regards,
Geoff
