CVP failing 2nd warm transfer with queuing

[vojkic]

Hello Everybody

I have a regular setup with Ingress GW, VXML GW, 2 SIP proxies, 2 CVPs, 2 CUCMs, 2 ICMs

Version of CVP is 8.0 (1) CUCM is 8.0.3.23900

VXML Gw is on 15.1(2) T$

Call Flow to agent is

InGW- CUSP - CVP-CUSP-CUCM-Agent1

When agent answers and puts on hold, I get Multicast from local GW which is good

No, agents does the transfer. To route point 86624384. Icm returns label with Corellation ID, and the call is routed for queing to CUSP and CVP.

Agent1- CUCM- ICM -CUCM-CUSP-CVP-VXML

the CVP finds new agent and connects

CVP-CUSP-CUCM-Agent2

No the initial Ingress call is connected to agent2

When Agent2 wants to transfer again by the queuint mechanism, dialing route point, the caller is put on hold again, agents again dials CC using ICM label

Agent2-CUCM-ICM-CUCM-CUSP-CVp-VXML

SO caller is on hold, agent is in queue

As soon as the Agent2 presses transfer again, the caller is connected to VXML GW for queuing, which is good

When ICM find ready agent3, caller is removed from queue and my call is stuck

I receive bye messages on CUCM, and caller hears cvp error from ingress gw

So i Do not know if CVP can handle these much call legs

ON SIP Trunk MTP required is unchecked and I want like that so that i can hear Multicast MoH to save WAN bandwidth. RFC2833 DTM is set on trunks

Is this expected behaviour or there is some CVP bug?

Thank you in advance.

[Mark Pareja]

Would you be willing to upload your CVP call server logs?

Sent from Cisco Technical Support iPad App

[Mark Pareja]

In some additional thought your Agent- A that is transferring the call back to ICM and subsequently CVP should be using a CTI Route Point, thus CVP needs to be aware of these cTI-RP the RP DN needs to be configured In ICM and the CVP PG also needs to be associated. Confirm that first, next make sure CVP or CUSP ( if using SIP Proxy) has a route for the CTI RP because ultimately a re-invite needs to make its way back to UCM in order to complete the transfer to Agent-B after queuing. If both of these are not the issue then I would need to see your call server logs, VRU PG PIM logs and CM PG PIM logs to accurately diagnose what is happening.

Sent from Cisco Technical Support iPad App

[vojkic]

Hello Mark, thanks for responding

I confirm, there is CTI RP in CUCM that is registered, beause there is DN in ICM. CVP PG is associated, and I can make calls by dialing that RP from IPT system, and I can make transfers to CTI RP when Agent A answers the phone. SO he can answer the phone and dial RP, the call is in queue and he can make the transfer. Yes tehere is a route pattern on CUCM that points to SIP Proxy for the purpose of calling the label returned by ICM.

The problem comes if Agent B transfers while the call is in queue.

I made some tests and it is like this:

1. If Agent A uses consult transfer (transfers to cti RP and waits to Agent B to asnwers) and then transfer - works fine

Later Agent B does same consult transfer to Agent C (over RP) - works fine

2.  If Agent A uses  consult transfer (transfers to cti RP and waits to Agent B to asnwers

and then transfer)  

Later Agent B does Warm  transfer to Agent C (over RP, but pressing Transfer for second time in CAD while call still in queue) - does not work, as soon Agent C presses Answer in CAD the call is dropped.

3.

If Agent A uses Warm  transfer to Agent B

(transfers to cti RP pressing Transfer for second time in CAD while call still in queue)  

Later Agent B does Warm  transfer to Agent C (over RP, but  pressing Transfer for second time in CAD while call still in queue) -  does not work, as soon Agent C presses Answer in CAD the call is dropped

4.

If Agent A uses Warm  transfer to Agent B

(transfers to cti RP pressing Transfer for second time in CAD while call still in queue)   

Later Agent B does same consult transfer to Agent C (over RP) - works fine

I have logs for case number 3. From CVP and CUCM. I believe it is CVP whos is dropping the calls. LEt me organize the logs tomorrow or day after and I will upload them

Thank you once again!

[jwilliams]

I thought in sip trunks MTP required should be ticked otherwise these type of issues occur
Sent from Cisco Technical Support iPad App

[vojkic]

Hello

here are the logs from CVp1 and CVP2, CUSP1 and CUSP2, CUCM1 and CUCM2

Time iz prrsensted as 7 hour difference. CVP and CUSP have same hours so in the logs you will see 12:58 12:59, on CUCM logs you will see 7 hour difference which will show 19:58 amd 19:59. VXML gateway is actually showing mal time so it is 11:58 or similar

All the logs are for same call

The Ip addresses are

CVP1 194.9.128.138

CVP2 194.9.128.173

CUSP1 194.9.128.142

CUSP2 194.9.128.177

CUCM1 10.162.8.6

CUCM2 10.162.8.7

Ingress Gateway is 10.170.128.1

VXML Gateway 10.170.128.13

Ip Phones that are called have DNs 86624311 and 86624310

Sig digits are 7662

ICM label returned to CUCM PG by ICM for calls hitting route point is beginning with 88880770, and sig digits are added by CUCM 7662

The call flow is like this

Ingress Gw- CUSP-CVP-CUSP-Agent1

agent1 86624311 answers  CVP2 log - 12:58:18

Agent 1 transfers to CTI routepoint 86624382

While call still in queue, he hits CAD transfer again and the call comes to second agent Agent2 86624310 CVP1 log - 12:59:01

Agent 2 transfers to CTI routepoint 86624382

While call still in queue, he hits CAD transfer again while the call comes to 3rd agent Agent1 86624311 CVP1 log - 12:59:14

After that Agent 3 tries to answer but the call is break down. The caller is hearing silence and then CVP error message played by Ingress GW.

At the same time VXML Gw receives Bye message from CVPm so do CUCMs

The logs when the Errors are seen in CVP1 and CVP2 are CVP1 12:59:18 CVP2 12:59:22

jwilliams, exactly that is solving my problem, ticking MTP reuqired, BUT if I do that I have Music on Hold distributed from central CUCM servers, because MTP does not support Multicast MoH. So i want to switch that off. Also, my colleagues do not have that problem with some newer versions of CVP and MTP reuqired UNCHECKED

[sajid_ahmad1]

Did you find a fix for this issue ?