cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1587
Views
0
Helpful
3
Replies

CVP Rona disconnecting answered calls

boyd.lynn
Level 1
Level 1

I’ve got a customer where the CVP RNA timeout is 22 seconds and the ICM Desktop Settings Ring No Answer time is 20 seconds. Quite often they are reporting that they answer a call but it appears to be pulled back by CVP a few seconds later and I can see the call routed to another agent. I am guessing that this may be due to the difference between the two timers only being 2 seconds. Does this sounds correct?

I thought that I would increase the CVP RNA timeout to 25 seconds but I am worried that this will make it longer than Call Manager Forward No Answer Timer. However when testing this in my lab I have noticed that RONA works fine with these settings even though the Forward No Answer Timer is set to the default value of 12 seconds. Can somebody please explain?

3 Replies 3

geoff
Level 10
Level 10

You are on the right track - these three timeouts have a relationship to one another.

For RONA, you want to make sure that the system makes the RONA agent not ready just before the call is taken away by CVP and it exercises Router Requery to find another agent, otherwise it could find the dud agent again - and you don't want that.

You definitely want the Call Manager timer well out of the picture. The SRND and the Config Guide do discuss these three timers, so check the documentation again.

Regards,

Geoff

Kris Lambrechts
Level 1
Level 1

So indeed these 3 timers have a close relationship, the typical setup would be : Agent Desk Settings < CVP RONA < CUCM Call Forward. So that comes down to :

  • The Agent PG (specifically the PIM) should make sure that we know that the agent didn't pick up his call, so that after 2 failures to answer he's marked as Not Ready, as Geoff already said, the main goal here being that we can't route the call again to that same agent;
  • The CVP RONA pattern is the amount of time CVP waits before assuming the agent isn't going to answer and where it requeries the UCCE Router for another agent;
  • The CUCM Call Forward setting should indeed be well beyond the timers defined in CVP and CCE, we don't want it to interfere with the Contact Center operations, if it's 12 seconds on your setup, that probably means that you don't have a Call Foward destination configured on the agent lines, basically disabling the CfwdNoAnswer setting on this line.

As for your actual issue, no that probably isn't due to the difference in timers. As said, the Agent Desk Settings RNA timer are used only to set this agent's state. Determinng whether the agent answered in time and requerying the Router is all up to the CVP Call Server. So if the agent answered but CVP still pulled back the call, that can only really mean that 'answer' event didn't reach CVP 'quickly enough'. I've seen this once or twice before, typically in enviorments where the call travels through PSTN from CVP to the agents. So when the agent answers his phone, the CUCM (or whatever PBX you're using) responds with an H.323 CONNECT / SIP 200 OK back to the caller (here, CVP), let's say it takes 2 - 3 seconds in voice signaling delay (SIP proxies, ISDN gateways, telco network, ...) between the agent actually answering and CVP receiving that same CONNECT / 200 OK, that gives you 3 seconds in which the RONA timer can expire even though the agent answered.

This isn't typically an issue on IP only network though. Although there I guess there is the possiblity that the 'answer' signaling packet gets lost.

Can you clarify a bit what your setup looks like and whether the agent can actually talk to the customer in those few seconds ?

Hi Kris and Geoff thanks for the answers.

My customer’s configuration is

PSTN ---- Voice Gateway/VXML Browser -------- CUSP ---------- CVP --------- UCCE -------CUCM

FYI we have had serious problems with the WAN between the voice gateways (Call Centre) and UCCE servers (Data Centre). At one point the CUSP was losing sight of the voice gateways as it was not receiving responses to it's pings. This seems to have been resolved by upgrading the WAN (A 3rd party supports the network and CUCM so I have very little visibility on their config)

Since the WAN upgrade however I have had at least one instance of the problem described above where the call was marked as RONA'd but the agent said that they spoke to the customer briefly before the call was pulled back. The UCCE Termination Call Detail record for the call has a Call Disposition of 19 (Ring No Answer) but it shows a talktime of 0 secs.

As mentioned previously the difference between the UCCE and CVP RNA time is 2 seconds and I was thinking of upping this to 5 seconds as recommended by Geoff in a number of posts. I haven’t found any Cisco documentation that mentions 5 seconds as the appropriate time differential (or any other value).

Thanks for clarifying the CUCM Call Forward setting. We do not have a Call Forward destination specified so that explains why it is not kicking in.