CVP 3.1 question

Unanswered Question
Jul 10th, 2009
User Badges:

Does CVP actually touch the call? We are getting complaints of people getting disconnected after waiting in queue. I was under the impression that only the call manager touched the call, but after looking at logs on the CVP server I am starting to wonder.

Disconnecting call. Reason=Abandoned.

Is there a guide somewhere explaining how to trace a call from cradle to grave?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)

I'll phrase your question another way. In a self-service CVP application, does CUCM ever touch the call? The answer is no.

So yes, CVP really controls the call.

In CVP there are two legs to the call. The switch leg is there for the life of the call to give CVP the control it requires.

The VRU leg gets established to play messages in queue (and other VXML stuff) then is torn down and a leg established to the agent when the Call Router chooses the available agent.

You can definitely trace a call through the CVP logs from cradle to grave, but it takes a bit of work. You probably don't have the level of tracing you need at the moment, but that can be increased with App Admin.

Tracing is improved in CVP 4.0 and there is more detail.

One way a call can be disconnected by CVP (not caller abandon) is if there is some sort of scripting error. This can occur (for example) if you have a Run External Script and the attached NVU script has a short timer. But normally, CVP will not disconnect the call. But stuff happens - and stuff happens to CVP more than other systems. ;-)

Look in your scripts and see if any calls are coming out the X ports.

Check the Error.log on the CVP servers for a quick bit of insight before upping the trace.



david.macias Fri, 07/10/2009 - 08:07
User Badges:
  • Blue, 1500 points or more

Just a few more things. How long are they waiting in queue? How big is your ICM script? Does the router log show any information about disconnects?


kre8or2007 Fri, 07/10/2009 - 10:38
User Badges:

So CVP actually has call control, and hands control back to the Call Manager when queuing ends?


You helped to program the scripting, you should know!! If you could remember back a few years anyway. The wait time is usually around 20 minutes. I do see where the maximum node limit is hit (5000)and it fails to produce a route for it. This happens alot and always has. However, a long time ago when we were getting disconnect complaints I put a default route in to stop them from disconnecting.

>So CVP actually has call control, and hands control back to the Call Manager when queuing ends?

No, that's not the right way of looking at it. CVP never gives up control. When the agent becomes available it sends a message to CUCM (either SIP or H.323) to set up the call to the phone (SCCP). In a way, this leg is just like the VRU leg.

If the agent wants to give the call back to CVP, it can do this; and CVP is efficient about it - because it holds the switch leg. So it doesn't have to hairpin the call, but can tear down the leg at the agent and build a new leg to a new agent (or VRU script).

Hitting the 5000 limit is pretty clever. You must have a few nodes in the queue music / "all agents are busy" loop. With 30s of music, 60m wait time is 120 loops; and 40 nodes a loop is 4800 nodes. Am I missing something here? Could this be rationalized a bit? Anyway, that's an aside - and not your current issue.

Can you run a SQL query on t_Network_Vru_Script in the AWDB and sort on the Timeout to check. The default is 180 - longer than any CVP WAV file.



kre8or2007 Fri, 07/10/2009 - 12:04
User Badges:

I forgot to mention, some of these sites are geographically located elsewhere, and the call stays in the local gateway at that call center; so does the call come in from PSTN and go to CVP, and then get handed to the call manager after queuing?

david.macias Sat, 07/11/2009 - 06:01
User Badges:
  • Blue, 1500 points or more


Took me a while before I could remember who you worked for. Hope you're doing well. The call will go to UCM once an agent becomes available, otherwise the queuing is done in ICM via CVP. Have you been able to replicate this issue yourself?


kre8or2007 Mon, 07/13/2009 - 05:34
User Badges:


David - I am doing fine, still learning as I go. I think I've mastered scripting and have a general idea of how it all works (except apparently CVP) Hope you're doing OK as well

I don't believe it is happening that often that I could replicate it; I would have to wait in queue for 20-30 minutes to even try. I'm sending out an email for agents to report to me when a call drops.


I checked the timeouts and all of them are 180 except for one, which is 99999 for some reason, I changed it to 180 -- I am guessing this setting means to wait X number of seconds before disconnecting if that .wav file doesn't play

So does Call Manager ever touch a call destined for an agent? I am trying to figure out if we are possibly having troubles with Call Manager or with CVP so I know where to start.

When the Call Router chooses the appropriate agent, the information (the label) is passed through to the routing client who controls the call - and that is the CVP PG. In your case, using H.323, the Voice Browser will do a gatekeeper lookup to see who should handle the label, and the gatekeeper will return the IP address of a subscriber. So now the Voice Browser has to signal to CUCM over H.323, in other words over a gatekeeper-controlled trunk to CVP.

All these stars need to be aligned. ;-)



kre8or2007 Mon, 07/13/2009 - 11:31
User Badges:

Thanks for the info; it sounds like it's mostly calls that drop in the middle of the call and a few instances of static/echo

kre8or2007 Wed, 07/15/2009 - 11:32
User Badges:

Well, not getting very many disconnect complaints from agents, but got this one that said they ansered the phone and didn't hear anyone and then the call dropped. I tracked this call to where I see this error; I can't find error codes in any documentation that I have, does anyone know of this error or what document explains these errors?


Disconnecting call. Reason=Abandoned


This Discussion