Finesse doesn't publish some call data updates for transferred calls

[danmoreno]

Hi.

In UCCE 10.x system, Finesse doesn't publish some "CallDataUpdateEvent" notifications through XMPP.

Finesse logs are attached to this discussion. The scenario is the following:

1. An new incoming call is established by extension 10019, agent id 1403 --> Call id 67118473.

2. The agent makes a consult call to another queue (68014) --> Call id 2130706438.

3. The call is answered by an available agent (extension 10017, agent id 1505). During the process of routing the call to the second agent, the call id changes from 2130706438 to 16781676.

The log file contains several messages received form CTI server ("Decoded Message to Finesse from backend cti server") in which the new call id (16781676) is related to the original call id for the consult call (2130706438, see line 629 in log file), or even related to the primary call id for the main call, whan that call is transferred to agent 1505 (call id 67118473, see lines 1017 & 1032 in log file).

However, Finesse doesn't publish any notification through XMPP related to the call id change (none "Publishing XMPP Message Asynchronously" related appears in the log file).

We need to get the new call id (16781676) at the second agent (1505), through a Finesse notification.

Any ideas?

Thanks in advance.

[dekwan]

Hi,

Did you attach the wrong logs? I unzipped the file and it only contained one log file that was not the Finesse logs.

The way Finesse handles call id changes is that it will send a new dialog notification with the new id, then sends a DELETE event for the dialog of the old id.

Thanx,

Denise

[danmoreno]

Thanks for your reply, Denise.

Sorry, I atttached the wrong log file. Here's the right one.

Unfortunately, in this failure case, Finesse doesn't send to the agent any notification with references to the new call id (16781676).

Thank you very much for your help.

Regards,

Dan

[dekwan]

Hi,

Thank you for the scenario details and your log analysis. You are absolutely correct that Finesse receives the CallDataUpdate event that the call id changes from 2130706438 to 16781676, but doesn't send a notification of this change. If you actually look at the notifications that are sent after this call data update event, Finesse actually continues using 2130706438 and publishes notifications using 2130706438 while the CTI server is sending messages for 16781676.

I am assuming that you are not using the Finesse REST APIs to do any of these call actions since I do not see any REST API requests in the logs. How are these call actions being triggered? Is it via the phone itself? Or do you have a call control application?

Is this issue reproducible? For just these agents or all? If so, have you tried to do this via the Finesse desktop? Based on the fact that we do not get a notification for the call id change, I would expect the desktop to get stuck because it would be making the REST API requests using the old call id and get an error.

Lastly, your scenario is a very basic and common thing that agents do. So I am trying to figure out what is different. Any ideas in terms of special configuration? Special type of phone? Does this setup have precision queues? I see that the call id changes between the CTIBeginCallEvent and CTICallServiceInitiatedEvent, which is very weird. This call id change is being done by CCE itself.

Thanx,

Denise

[danmoreno]

Hi, Denise.

We develop a call control Java application. It triggers the call actions to Finesse, through HTTP, and receives call events through XMPP.

All agents use Cisco IP Communicator softphones, and the issue is reproducible for all agents and queues configured.

I'll test this failure case via the Finesse desktop, and I have requested information to administrators about the configuration of that Cisco system, especially everything related to the routing of incoming calls and the hardware modules involved in that action flow.

I'll publish all this information ASAP.

Thanks,

Dan

[danmoreno]

Hi.

I have attached new logs related to this issue. The scenario for this new test is the same:

1. An new incoming call is established by extension 10019, agent id 1402 --> Call id 67121155.

2. The agent makes a consult call to another queue (68014) --> Call id 2130707107.

3. The call is answered by an available agent (extension 10017, agent id 1502). During the process of routing the call to the second agent, the call id changes from 2130707107 to 67121156.

Both agents used Finesse Desktop for this test.

Finesse server log file (LogFinesseL900_29032016.txt) includes events until the "ALERTING" notification to agent 1502, for the consult call. I also included logs for both Finesse Desktops. I got them from the Internet Explorer console, running the browser developer tools (by pressing F12 key)

The new call id (67121156) is still missing in XMPP notificactions.

Regards,

Dan

[dekwan]

Hi,

Thanks for the logs. It looks like the webservices logs were cut off a little early but that might be ok. I did find something interesting though. Based off of the agent 1502's logs, it looks like you were able to perform the scenario from start to finish without any errors on the page. I saw that 1502 answers the call using the old call id (2130707107) and it was successful since a correct XMPP event comes back:

   2016-03-29T08:58:09.276 +02:00: : iv3to0309.itg.merc.es: Mar 29 2016 08:58:10.799 +0200: CallControl : [ClientServices] Dialog: requestId='8559aed5-036c-49ab-8ff1-1d76406b7c8d', Making REST request: method=PUT, url='/finesse/api/Dialog/2130707107'

   2016-03-29T08:58:09.276 +02:00: : iv3to0309.itg.merc.es: Mar 29 2016 08:58:10.799 +0200: CallControl : [ClientServices] Dialog: requestId='8559aed5-036c-49ab-8ff1-1d76406b7c8d', POST_DATA='<Dialog><targetMediaAddress>10017</targetMediaAddress><requestedAction>ANSWER</requestedAction></Dialog>'

I vaguely remember that for some situations, Finesse maps the old call Id to the new call Id internally where you can continue to use the old Id without a problem, but for some reason I can't find any documentation on it. This might be the case in this situation since agent 1502 was still able to perform actions on the call using the old call id. In the Finesse server logs, search for the requestId above 8559aed5-036c-49ab-8ff1-1d76406b7c8d. Around there, there should be an AnswerCallReq which is the answer request that is made to CTI. Look at the callId that it is using. Is it 2130707107 or 67121156?

Here is an example log snippet for the time when agent 1403 answered the call (call Id 67121155): 0025878294: 172.28.79.70: Mar 29 2016 08:57:23.278 +0200: %CCBU_pool-5-thread-125-6-MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :8145671 , callId: 67121155, extension: 10019, peripheralId: 5000, connectionDeviceIdType : 0, connectionDeviceId: 10019][cti_message_name=AnswerCallReq]: Message going to the backend cti server

Is this an issue for your application? Can you just use the old call id even though there is a new one?

Thanx,

Denise

[danmoreno]

Hi, Denise.

You are correct. Our application handles the Finesse events correctly, even though the call id is the old one. However, this is an issue for us, because the application is also integrated with the Verint recorder, and we can't match the call ids, to find the calls in the recorder database.The Recorder uses JTAPI to handle the call events, and for that calls, the id included in the events is the new one.

Broadly speaking, the basic flow for incoming calls, at the 68014 queue, is:

- Incoming call arrives to IPCC Gateway for the call center.

- IPCC Gateway consults in CCM which number must be the receiver of the call .

- IPCC CCM sends the information to PG (a bridge to reach the Rogger).

- PG processes the information and consults in Rogger what to do with the call.

- Rogger needs more information to make a decisión (schedule of attention, black lists, …) and queries that info to PG.

- PG forwards the queries to IVR.

- IVR request the info through WS (that info is stored in an external database).

- IVR returns to PG the info requested.

- PG returns to Rogger the info requested.

- Rogger analizes the info and returns the decision about the available agent assigned to the call.

- PG books the chosen agent id and notifies the booking to Finesse.

- PG notifies the chosen agent id to CCM.

- Finesse books the agent for this call.

- CCM queries the agent id and sends its associated IP / port to IPCC Gateway (to connect the call).

- The call is established, through the gateway, between agent and customer.

- The call is sent to the recorder (Switch ports are configured in SPAN mode).

- Recorder controls that call signals, for synchronizing the data received.

in case of not being able to get the new call id in the "id" field of Finesse events, I wonder if it would be possible to configure anything in the Cisco system involved in that flow, for storing the new id in a call variable field of the XMPP events.

Thanks,

Dan

[dekwan]

Hi,

I can see how that becomes a problem for your application. Unfortunately, from a Finesse perspective, everything is working fine since the agent is still able to use the old call id. I would suggest opening a TAC case who could work with both the UCCE and Finesse team directly to try to come up with a solution to your problem.

Thanx,

Denise

[danmoreno]

Hi, Denise.

We also opened a TAC SR, In case they can solve the issue I'll post the solution.

Thank you very much.

Best regards.

Dan

[dekwan]

Hi,

Awesome. I hope they jointly come up with a solution that can solve your problem. I can see others having this same issue so it would be great if you can post the solution.

Thanx,

Denise

[danmoreno · Accepted solution]

Hi.

Cisco included a bug for solving this issue in a future major versión, maybe 12.x:

“CSCuz22201    Cisco Finesse XMPP is not updating Call ID for the transffered call”

                 https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz22201

Regards.

Dan