CVP call server logs - Hi All, I am trying to figure out whether caller party(End User) hangup the call first or UCCE Agent

[Srinivas Divakar K]

CVP call server logs

 Hi All,

I am trying to figure out whether caller party(End User) hangup the call first or UCCE Agent.

Attaching CVP call server Logs& UCCE TCD& Route Call Details for your reference.

[Jameson Gagnepain]

Unfortunately, you're not going to find anything in TCD or RCD about who hung up first, and I'm not seeing anything in the CVP logs to indicate one way or another... I don't know of any SIP messages that would indicate the caller or called party being the one to end the call.

One potential solution for this for future tracking:

• Using the CVP post-call survey functionality, send all calls (technically all calls where the agent hung up on the caller) to a new DN and script.
• In the new script, just apply a call type (perhaps something like "Agent_Hangup"), and then use a "CAP" microapp Network VRU Node to have ICM record that moment's call data into the TCDR. Follow that with a call termination.

With the above solution, you should be able to look at entries in the TCDR to see which calls did or didn't have Agent_Hangup call types on them. You can potentially setup custom reporting on this.

-Jameson

[Srinivas Divakar K]

Can i figure out from CVP call server logs whether Caller(End User) hung up during the middle of conversation with an agent ?
 

[Jameson Gagnepain]

How would CVP know if someone is in the middle of talking? The RTP audio stream doesn't traverse the CVP server. A hangup "in the middle of a conversation" or at the end of a conversation looks exactly the same to every device involved.

If you wanted to find out if calls are ending in the middle of someone talking, the most appropriate solution would probably be call recording, together with someone listening to the recorded calls.

-Jameson

[Abu Hadee]

From the CVP logs, it can be determined which side disconnected the call first. For each call, CVP keeps track each call leg. From Inbound Gateway to CVP is INBOUND leg, rest are OUTBOUND leg. You can then look at which leg the SIP BYE message is received first.

Since you have very basic log enabled, you will not see the exact SIP message. But it can be determined by the outcome of the message. Here is the snippet of the log during the disconnect:

Line 3766: 3083689: 10.180.245.43: Sep 12 2014 12:21:11.293 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DIALOG_CALLBACK.6} CALLGUID = CBCCDD8539E811E4A3E2CCEF48565980 LEGID = CC65CE04-39E811E4-87DFD7D1-64B198F2 - [INBOUND] DURATION (msecs) = 25610 - DIALOG TERMINATED. Reason: Q.850;cause=16

Line 3768: 3083690: 10.180.245.43: Sep 12 2014 12:21:11.293 -0700: %CVP_8_5_SIP-7-CALL:  {Thrd=DIALOG_CALLBACK.6} Sending BUS MSG:>>HEADERS: (JMSType)=MsgBus:CALL_STATE_EVENT (JMSDestination)=Topic(CVP.SIP.CC.EVENT) (JMSTimestamp)=1410549671293 >>BODY: callguid=CBCCDD8539E811E4A3E2CCEF48565980 RouterCallKey=6472 RouterCallKeySent=true causecode=1 timezone=America/Los_Angeles RouterCallKeySequenceNumber=0 version=CVP_8_5 labeltype=1 RouterCallKeyDay=151099 calldate=Fri Sep 12 12:21:11 PDT 2014 label=190376 localOffset=-420 eventid=6 calllegid=CC65CE04-39E811E4-87DFD7D1-64B198F2  >>STATE: isTabular=false isWriteable=true cursor=-1  

The first Termination message came on the INBOUND leg which is the PSTN. That means, PSTN side disconnected the call first.

Hope this helps.

Abu

[Srinivas Divakar K]

Thanks Abu and Jameson