CVP 12.6.2 differentiate between hangup and disconnect events

[ja.kriventsev]

CVP Application 12.6.2. to differentiate between hang up and connection to agent events.

Hi Community !
I have a cvp application for a queue. a caller stays online and hears the music in this application. If the caller ends the call without  connecting to an agent, I want to send an email to the supervisor. If the agent accepts the call, do nothing.
So I have a problem. I can't differentiate between two disconnect events in the cvp app. For my cvp application, the "hangup" event and "disconnect due to transfer to agent" event look like the same as the VXML Connection.disconnect event.

other event handlers do not react (do not respond) to the disconnecte events in the app. only Connection.*, Connection.disconnect

App (event handling) worked in 11.5 and stop working after upgrade to 12.6.2.

Please tell me how to solve the problem in 12.6.2. Thanks a lot!

[bill.king1 · Accepted solution]

I don't know the answer to your main question re: what changed in 12.6.2, hopefully someone else can answer, but I thought you might find this defect re: the vent handling in general of note. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvj77314 It looks old but then was updated this year and shows as fixed? Hope this helps.

[janinegraves]

Hi,

I don't believe VXMLServer was *ever* able to distinguish between the caller hanging up vs. ICM interrupting the app to send the call to an agent.  However, there is a distinction in the Cisco/CVP/logs/cvp.date.log - so if you need this information, you can find it there.

When I tested this just now on my 12.6.1 system, I can clearly see in the VxmlServer Debug logs that the VVB sends VXML Server the same information regardless of whether the caller hung up, or ICM interrupted and send the call to the agent:
audium_type: connection.disconnect
audium_action: hangup

And in both scenarios, my application exited down the event handler for: connection.disconnect
and never exited down the connection.disconnect.hangup or the connection.* event handlers.

The difference can be seen in the  Call Server log Cisco/CVP/logs/cvp.date.log after the final Run_Script_Request for  GS,Server,V 

a) If the caller hung up, I seefrom the SIP SS: [INBOUND]: DURATION (msec) = nnnn - DIALOG TERMINATED. Reason: Q.850;cause=16

b) Whereas, if ICM interrupted to send the caller to an agent I see from the  ICM SS: [IVR_VRU_LEG_DIALOGUE] - Processing from UCCE - [CANCEL]

I'm uploading the part of the log beginning with the final RUN_EXT_SCRIPT so you can see.

So - you'll need to tie together either the ICM database tables or the CVP Call Server logs with the VXMLServer application log to get more info on how the call is ending.

HTH
 

[ja.kriventsev]

Hi Janine! Thanks a lot for the investigation.

I'll check the logs and make some test in old 11.5 env. 

Perhaps we were mistaken when we thought that the application reacted correctly to the client's leg break in 11.5. Although the call center did not let us sleep if emails came after the agent received the call.