Hello,
I have a JTAPI application in a customer call center that monitors CTI events on agent terminals. Additionally, I have a 3rd party gadget running in the Finesse desktop and I need to correlate calls between these two applications.
I found that the Dialog ID from Finesse (almost always) matches exactly with the intValue provided from the CiscoCallID associated with the JTAPI CTI event. Roughly I have something like this in my JTAPI application
public class Handler implements CallControlCallObserver {
...
public void callChangedEvent(CallEv[] events) {
for (CallEv ev : events) {
CiscoCall ciscoCall = (CiscoCall) ev.getCall();
int finesseDialogId = ciscoCallID.intValue();
// do logic with the Finesse Dialog ID
}
}
}
This system has been working at multiple customers without issue across tens of thousands of calls. However... There is one customer for whom this logic does not work on a small percentage of calls. In these cases, I get a different value between JTAPI and Finesse.
To give a more concrete example, here is a dialog event received from Finesse. This was right after the agent answered the call and a few milliseconds later DN 8053 dropped.
{
"mediaProperties": {
"dialedNumber": "4900",
"queueName": "Service",
"DNIS": "4936",
"queueNumber": "7",
"callType": "ACD_IN",
"callvariables": {
"CallVariable": [
{
"name": "callVariable1",
"value": "4900"
},
{
"name": "callVariable2",
"value": "Service"
},
{
"name": "callVariable3",
"value": "DIRECT"
},
{
"name": "callVariable4",
"value": "4770"
},
{
"name": "callVariable5",
"value": "10"
},
{
"name": "callVariable6"
},
{
"name": "callVariable7"
},
{
"name": "callVariable8"
},
{
"name": "callVariable9"
},
{
"name": "callVariable10"
}
]
}
},
"fromAddress": "4770",
"mediaType": "Voice",
"id": "44908433",
"state": "ACTIVE",
"toAddress": "4900",
"uri": "/finesse/api/Dialog/44908433",
"participants": {
"Participant": [
{
"stateChangeTime": "2024-01-16T15:31:48.395Z",
"mediaAddress": "4936",
"mediaAddressType": "AGENT_DEVICE",
"startTime": "2024-01-16T15:31:48.395Z",
"state": "ACTIVE",
"actions": {
"action": [
"CONSULT_CALL",
"UPDATE_CALL_DATA",
"START_RECORDING",
"SEND_DTMF",
"HOLD",
"DROP",
"TRANSFER_SST"
]
}
},
{
"stateChangeTime": "2024-01-16T15:30:38.285Z",
"mediaAddress": "4770",
"startTime": "2024-01-16T15:30:38.285Z",
"state": "ACTIVE",
"actions": {
"action": [
"CONSULT_CALL",
"UPDATE_CALL_DATA",
"START_RECORDING",
"SEND_DTMF",
"HOLD",
"DROP",
"TRANSFER_SST"
]
}
},
{
"stateChangeTime": "2024-01-16T15:31:48.402Z",
"mediaAddress": "8053",
"stateCause": "OTHER",
"startTime": "2024-01-16T15:30:38.285Z",
"state": "DROPPED"
}
]
}
}
Within a few milliseconds our JTAPI application received a ConnConnectedEv for the same agent, but the intValue for the event was 44908424, not 44908433 like I would expect from the Finesse event above. JTAPI does show that the CallingAddress for the event is 8053 though, which matches a DN from the participant list in the above event.
Immediately after that, we get a CallCtlConnEstablishedEv for the extension, again with an intValue of 44908424, but this time with a call address that looks like a normal 10 digit external phone number, which is what we were expecting for the call. At no point does Finesse report a participant with a 10 digit external phone number, but the customer has confirmed with us that these are inbound calls with customers, not something internal between other agent DN's.
I have noticed that this behavior only occurs when the call is routed to a certain DN, but I can't figure out why it appears so different than any of the other ACD calls we process.
Does the behavior described above correspond with any type of call routing that you are aware of? Alternatively, is there another place to retrieve the corresponding Finesse dialog ID from the JTAPI call event other than calling intValue on the CiscoCallID? We do not see the Finesse dialog ID above anywhere in our JTAPI logs, and none of the corresponding values received by JTAPI are in the Finesse logs, so we are stumped as to what is going on here.
