Without any other call flow details, my guess would be that you have the call flow for transfers back to CVP configured incorrectly.  There are many ways to do it functionally, but you need to have it set up as described in the Config and Admin Guide to keep the ICM side of things in check.  A quick summary (and assuming you are using UCCE):
 
1. Network VRU Type in ICM should be set to Type 10.
2. Transfer Label should be configured under Type 10 NVRU for *UCM Routing Client*
3. Transfer should be made to a CTI Route Point on UCM that is associated to the ICM PG User.
4. Dialed Number configured in ICM for *UCM* Routing Client, pointing to same script that routed the first leg of the call.
5. When "Send to VRU" is encountered, ICM will return Transfer Label to UCM.
6. UCM should have Route Pattern to take this Label (make sure you have "!" at the end, as it will have a Correlation ID appended) and send it to CVP via whatever means you wish (direct to Trunk, Route List, etc. depending on whether SIP or H.323)
7. CVP will then pass call to ICM, but ICM will recognize it as the same call, and call context will be maintained.
 
Basically, any transfer that involves moving the call from a Routing Client to another Peripheral is, by definition, a Translation Route scenario, but UCCE with CVP and Type 10 NVRU allows this function with Correlation ID instead of typical Trans Route DNIS configuration.
 
There are good details on the configuration of this call flow in the CVP Config and Admin Guide.
 
 - Bill

Manoj,
 
What would be the process or solution for the below scenario :
 
Customer -> CVP -> agent -> CVP   call wait for 60 sec to input customer PIN change/Card Number and after 60 sec timeout call lands back to same agent
 
 
Cheers,
 
 
 


Bill has provided all steps required for Warm transfer. Thats exactly how you need to do a warm transfer which would maintain the call context. To add few points:
1) It could get a little complex when you have a distributed Ingress gateway and VXML gateway. SigDigit would help you a great extent if you had already configured.
2) If you have configured "send the call to orginator" label to send the call to VXML gateway. Then in H323 you have to setExcludeIP to CUCM IPs in the voice browser of CVP. In SIP, I guess you have use static routes/SIP proxy with SigDigit to decide on the VXML gateway.
 
Manoj Anantha
 

Without any other call flow details, my guess would be that you have the call flow for transfers back to CVP configured incorrectly.  There are many ways to do it functionally, but you need to have it set up as described in the Config and Admin Guide to keep the ICM side of things in check.  A quick summary (and assuming you are using UCCE):
 
1. Network VRU Type in ICM should be set to Type 10.
2. Transfer Label should be configured under Type 10 NVRU for *UCM Routing Client*
3. Transfer should be made to a CTI Route Point on UCM that is associated to the ICM PG User.
4. Dialed Number configured in ICM for *UCM* Routing Client, pointing to same script that routed the first leg of the call.
5. When "Send to VRU" is encountered, ICM will return Transfer Label to UCM.
6. UCM should have Route Pattern to take this Label (make sure you have "!" at the end, as it will have a Correlation ID appended) and send it to CVP via whatever means you wish (direct to Trunk, Route List, etc. depending on whether SIP or H.323)
7. CVP will then pass call to ICM, but ICM will recognize it as the same call, and call context will be maintained.
 
Basically, any transfer that involves moving the call from a Routing Client to another Peripheral is, by definition, a Translation Route scenario, but UCCE with CVP and Type 10 NVRU allows this function with Correlation ID instead of typical Trans Route DNIS configuration.
 
There are good details on the configuration of this call flow in the CVP Config and Admin Guide.
 
 - Bill