CVP - Warm Transfers -SIP

[adignan]

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.

[adignan]

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]

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]

We are able to get a call to the agent from CVP fine.

[jawilson_1]

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]

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]

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

[adignan]

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]

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

8888888881!

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]

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.

[sidney.orret]

interesting info. Thanks!!!

[mwadam]

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

First problem was a fat finger on my part. The CVP server is 10.102.1.125 and throughout our testing I had changed the address to CallManager which is 10.100.1.100. 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 10.100.98.97 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 10.100.101.97. 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]

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*.

Sorry.