Solved: Determining the releasing party

muratilkdogan · ‎11-08-2016

Hi,

We need to determine the party (agent or customer) releasing the call. Although CallConnectionClearedEvent ReleasingDeviceID field seems like providing this information, we observe that regardless of the actual releasing party, we receive 2 consecutive CallConnectionClearedEvent messages, first of them having the agent device ID as ReleasingDeviceId and the second one having the customer device ID as ReleasingDeviceId.

Is there a different method or configuration to determine the releasing party for a call?

Best Regards,

Murat

dreich · ‎12-13-2016

The ReleasingDeviceID field does not reliably reflect who hung up the call. The information we get from UCManager component does not imply who hung up first. We've updated the CTI Server protocol spec in later versions to reflect this.

The only component in the solution that tracks this information reliably is the UCManager in their CDR records.

For calls that go through CVP, there is an attempt to flag cases where the agent hung up first via CallDisposition 52 in the Termination Call Detail record (TCD). It doesn't contain the agent ID or the skill group they're in, but you can correlate that information with the agent TCD using the common Router Call Key and Day. It's a bit complicated, but might be a better option if you don't want to dive into UCManager CDRs.

David

View solution in original post

dreich · ‎12-13-2016

The ReleasingDeviceID field does not reliably reflect who hung up the call. The information we get from UCManager component does not imply who hung up first. We've updated the CTI Server protocol spec in later versions to reflect this.

The only component in the solution that tracks this information reliably is the UCManager in their CDR records.

For calls that go through CVP, there is an attempt to flag cases where the agent hung up first via CallDisposition 52 in the Termination Call Detail record (TCD). It doesn't contain the agent ID or the skill group they're in, but you can correlate that information with the agent TCD using the common Router Call Key and Day. It's a bit complicated, but might be a better option if you don't want to dive into UCManager CDRs.

David

lboggs1984 · ‎12-14-2016

Hello, is this reliable information, however?

21:55:27:101 CTIOS1-ctios Trace: >>CG:[call.5002.92113213]:eCallConnectionClearedEvent(PrphID:5002 PrphTyp:17 ConnCID:92113213 ConnDevIDTyp:0 LclConnState:65535 EvtCause:65535 RelDevTyp:0 MonID:0 ConnDevID:63005101 RelDevID:63005101 MsgID:eCallConnectionClearedEvent DvrKey:call.5002.92113213)

21:55:27:101 CTIOS1-ctios Trace: >>CG:[call.5002.92113213]:eCallConnectionClearedEvent(PrphID:5002 PrphTyp:17 ConnCID:92113213 ConnDevIDTyp:1 LclConnState:0 EvtCause:65535 RelDevTyp:0 MonID:0 ConnDevID:8005551212 RelDevID:8005551212 MsgID:eCallConnectionClearedEvent DvrKey:call.5002.92113213)

21:55:27:102 CTIOS1-ctios Trace: >>CG:[call.5002.92113213]:eCallClearedEvent(PrphID:5002 PrphTyp:17 ConnCID:92113213 ConnDevIDTyp:1 LclConnState:0 EvtCause:65535 MonID:0 ConnDevID:8005551212 MsgID:eCallClearedEvent DvrKey:call.5002.92113213)

21:55:27:103 CTIOS1-ctios Trace: >>CG:[call.5002.92113213]:eCallEndEvent(PrphID:5002 PrphTyp:17 ConnCID:92113213 ConnDevIDTyp:1 ConnDevID:8005551212 MsgID:eCallEndEvent DvrKey:call.5002.92113213)

I noticed LclConnState and EvtCause may be indicative? In this case, the 8005551212 actually hung up per the CVP logs.

dreich · ‎12-27-2016

Hello Lindsay,

I'm not able to confirm that. Let me check into it. I'd be curious to know your results. We have a lot of people asking about this, and this would be a nice find.

David