CVP - Warm Transfers -SIP

Unanswered Question
Sep 12th, 2008

Curious what others are doing as best practice for Agent Warm Tranfers with SIP. Are you:

1. Setting up seperate SIP Trunks to the Call Servers with MTP checked

2. Creating JTAPI triggers

Seems tha the SIP trunk way would be a lot easier. Just curious if there are any drawbacks or things I am overlooking.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Chad Stachowicz Fri, 09/12/2008 - 20:07

So which way are you talking about? I use both no problem. So basically what I have noticed is if the call is initiated at CCM -> sip trunk -> proxy -> call server. This I use for all my Main Numbers. I made my dial-plan so that 4 digits come to ingress it prepends 2 digit CVP code in my case and prior posted configs (70xxxx). Well I also make a route pattern in CCM in a Site Specific Partition. This allows me to preference the right digits out the sip trunk with the magic 7th digit in the CCM Route Lists. With this in place I can always keep my CCM placed call on the correct side of the WAN like from PSTN with CVP. The same trick I use from my ingresses to control call routing. MTP needs to be checked on the SIP Trunks as you have mentioned. I highly suggest using MTP that is site specific and Hardware. Now I have sets of back doors. Basically its a CTI Route point to ICM and then it just queues directly to the skill group and plays music on hold. Everything seems to be in working order, and I have been told that the reporting looks differet for CTI Route points vs ones initited into the call server. I imagine thats only in the CVP Stats though for new calls processed with call handling through CVP. This is all I can see.

Anyways this works good for us, and also allowed things to become very organized for the purposes they serve in CCM ( I'm a CCM neat freak). However overall if it makes sense a single route pattern pointing to your sip trunk with MTP is the easiest and works just fine :)

BTW, how many CCM in this current cluster going up? Designing things to work like they should with a full 8CCM cluster took me lots of learning and tons of mistakes.



david.macias Sat, 09/13/2008 - 07:45


Can you be a bit more specific on how the reporting looks different?


Chad Stachowicz Sat, 09/13/2008 - 11:15


Well if it comes in over the SIP Trunk it looks like a New Call since it uses the New Call service. However if it comes in over ICM PG, it should be able to do a correlation form the person who transfered it in back to CVP and it should not look like a new call. Thats why my main numbers are over the SIP turnk and warm transfer to skill group is over ICM PG. I was told this by one of our experts, however I don't have a CVP reporting server so I can't check :)


jawilson_1 Thu, 09/25/2008 - 13:35

hi David :-) Have you successfully deployed CVP 7.0 with SIP Proxy?

jawilson_1 Thu, 09/25/2008 - 13:34

Chad: Regarding MTP will having it enabled in the software not work? We're having issues with SIP proxy and CVP 7.0 now. SIP is sending the invite back to CVP but it seems CVP is not either acknowledging or can't understand it. I think we're missing something in the config either on the SIP proxy or CVP.

adignan Thu, 09/25/2008 - 13:44

Software MTP just doesn't scale. Can you post your ingress gateway and vxml gateway config, screen shot of your CUPS Static Rout Page, and a screen shot of your SIP Service setup in Ops Manager?

mwadam Thu, 09/25/2008 - 13:55

I am working with Jocelyn. Attached are the gw config and the CUPS static routes. She will attach the Ops Mgr screen shot.

a little info:

2850 is our inbound number from the PSTN.

8888...'s are being used for warm transfer. There is a route pattern on CCM 888! to send this pattern via a separate sip trunk on ccm using port 5060 to the sip proxy. We see in the sip proxy trace files three separate invites sent to the CVP server but no response.



adignan Thu, 09/25/2008 - 14:03

looking over stuff now. are you using mtp on your trunk to CM? No need to.

adignan Thu, 09/25/2008 - 14:04

Can you also snag the CVP and Error logs from your Call Servers in the C:\Cisco\CVP\logs directory?

mwadam Thu, 09/25/2008 - 14:09

I originally had software MTP defined (500) but after the references in this thread I configured hardware MTP (40).


adignan Thu, 09/25/2008 - 14:11

hmmm....looks like the call is getting to CVP ok, but your GS microapp is failing because the TTS server is down.

I assume you see the call arrive at the ICM Script?

4351: Sep 25 2008 16:39:54.977 -0500: %CVP_7_0_IVR-3-CALL_ERROR: CALLGUID=0E4DE2558A8111DD80E30021D80B4370 DNIS=7777777771161 Primary TTS Server has failed. Sending error to ICM. [id:3023]

4354: Sep 25 2008 16:39:54.977 -0500: %CVP_7_0_IVR-3-CALL_ERROR: RunScript Error from [MEDIA_RESOURCE_TTS(32)] CALLGUID: 0E4DE2558A8111DD80E30021D80B4370 DNIS=7777777771161 {VRUScriptName: 'GS,Server,V' ConfigParam: ''} [id:3023]

adignan Thu, 09/25/2008 - 14:13

What if you just change to a basic PM Microapp for testing to make sure the routing is working.

For example:

PM,Friday,S to just play "Friday.wav" back from your Media Server.

adignan Thu, 09/25/2008 - 14:18

I just want to make sure direct calls from IP Phone to a basic script works first. After that, we can get the warm transfers working.

jawilson_1 Thu, 09/25/2008 - 14:15

Yes, we are aware that TTS has an issue as well but is this related to the warm transfer by agent too? Yes, we do see the call in the ICM script and you see it fails at the Send to VRU node. My other co-worker is working on TTS now. We're using Nuance with RealSpeak 4.5. Adam and I are working on the transfer issue while Sidney is working on completig the TTS configs. We really haven't found much documentation to assist with the TTS yet.

sidney.orret Thu, 09/25/2008 - 16:28

All (specially jaw and adm) :)

Just a comment here. Anytime we see a tts error, or for that matter a media file error the call is already connected to the IVR way past of the point of the current failure.

The error we are experiencing is that when ICM sends the vru label back to CCM the call never gets connected to CVP as it is supposed to be.

rajasekarvs Fri, 09/26/2008 - 00:41

Any inputs would be appreciated ,as we are also hitting the same issue...Raj

adignan Fri, 09/26/2008 - 03:02

I am not sure you can get Warm Tranfsers to work by using the "Route Pattern" method for Warm Transfers with CVP. I think you have to use the "Route Point" method.

1. Delete your 8888 Route Pattern in CallManager

2. Create a Route Point of 8888 and associate to PGUser

3. In CallManager create 5 Route Patterns with the following pattern and point to the CUPS Trunk for the gateway

- 777777777x

- 777777777xx

- 777777777xxx

- 777777777xxxx

- 777777777xxxxx

4. In ICM Configuration Manager, create a label of 777777777 associated to the CallManager Routing Client

5. Create a Dialed Number of 8888 associated to the CallManager PG

6. Associate your Dialed Number 8888 to the Call Type that will trigger your script

sidney.orret Fri, 09/26/2008 - 05:49

I am working this issue with jocelyn, adam too. Let me clarify a bit.

We do have the route point (2851) in CCM, also we have the ICM DIaled Number and Call Type. The Network VRU label for CCM.rc is 8888888881 and we see the label sent back to CCM whenthe ICM script hits the SendToVRU block.

Now what I am curious about if you can clarify is why you created the 5 Route Patterns, I am assuming to match CorrelationIDs up to five digits.

that in our case would be

- 8888888881x

- 8888888881xx

- and so on.

We have one route pattern that is


The reason I am curious, if because I am starting to get concerned about the pattern matching capabilities of Cisco products. :( We hit a issue with one dial-peer in the GW that was fixed shorting the matching pattern, even when the longer pattern in theory had to match the incoming label.

So, do you have any recommendations on why to create the 5 route patterns in CCM, rather than just one, matching everything with a !?

adignan Fri, 09/26/2008 - 05:52

Hehe. Once would assume (as did I) that the ! would work. However, because of the interdigit timeout caused by the ! wildcard, it fails. In the CVP config guide, its actually called out to create the specific route patterns.

mwadam Fri, 09/26/2008 - 09:07

Here is what we came up with to solve the problem.

First problem was a fat finger on my part. The CVP server is and throughout our testing I had changed the address to CallManager which is When I changed the address in the static route in the SIP Proxy server back to the correct address I neglected to change the second octet. Once this was fixed the call now made it to CVP.

The 888* static route in the SIP Proxy was being sent to which is an interface on the ingress gateway. This is the same address we were sending all other calls such as ringback and error messages. Since the call was coming from CallManager at this point, sending the 888* string to the above address was being denied on the return leg back to CallManager because the above address was not a registered device (h323 gateway). To solve the problem I changed the static route in the SIP proxy server to the registered h323 gateway IP Address of Since CallManager now sees the request coming from a registered device it allowed the call to be processed.

The warm transfer feature now works!!!

Thanks for everyone's assistance.

mwadam Fri, 09/26/2008 - 09:14

Correction to my notes.

I changed the static route ip address for the VRU label in the SIP Proxy from the unregistered ingress/vxml gateway ip address to the registered ingress/vxml gateway ip address. Not the 888*.



This Discussion