Finesse not updating CTI Data for transfered calls

[Hossain Ahmed Ashfaque]

Hi,

I am using PCCE 10.5 and using Finesse 10.5.

In ICM script I am passing CTI data via Call Variable1, Call Variable2, Call Variable3, Call Variable4 and Call Variable5. When the agent answer new call then the agent can see all the data in Finesse screen.

Now if the agent transfer to the call to another queue and before queuing the call I change the Call Variable3 in ICM script so that it reflect the new queue name. Now there are 2 scenario

1. No agent available in the new queue, caller hear the queue music after that agent become available and answered the call. This case agent call the Call Variable3 updated with the new Queue name.

The problem is

2. If the agent is available in the new queue and answer the call then Call Variable3 does not update and agent see Old queue name.

I capture dump log from cti server and can see that Call Variable3 updated before reaching the second agent and Finesse logs showing that it receive the updated value of Call Variable3. So wondering why Finesse does not show the updated value.

So is there any difference in Finesse screen pop if the call is answered after passing the queue node and if the call is directly answered from the queue node?

Thanks,

Ashfaque

[dekwan]

Hi,

Are you using the Finesse desktop out of the box? In order to answer your question correctly, I would need to see the webservices logs and the matching client logs to see what is going on.

Also, when you say Finesse screen pop, do you mean a workflow screen pop? Or are you referring to the call variable layout in the call control gadget. Providing a screenshot of the issue would be good too.

Thanx,

Denise

[jap_santi]

Hi Denise,

I am replying on behalf my friend Hossain.

We use the default call control gadget and populate the call queue by grab the call variable 3  value from ICM script.

We notice if the call straight away answer by the agent, the call queue never refresh.

I see the log and I could not find the new dialog id.

Below is the log:

Mar 18 2016 16:39:54.640 +0800: CallControl : [ClientServices] {"content":"/finesse/api/User/1002/Dialogs1416168003241415TRANSFER2900callVariable1Y|Y|N|EN|2900callVariable2S1234567D|T1234567JcallVariable3CC_Code_1_1_PQcallVariable4219-151652-0callVariable51416callVariable6ENcallVariable72981callVariable8callVariable9callVariable10user.microapp.ToExtVXML[0]application=EnableCSSuser.microapp.FromExtVXML[0]Y|Y|N|EN|2900user.microapp.error_code0user.media.idE72871800001000000000042691EB60Auser.microapp.isPostCallSurveyYuser.microapp.metadataN|000|01|00|00|007675|GS,Server,V,interruptuser.microapp.ToExtVXML[2]user.microapp.FromExtVXML[3]user.microapp.ToExtVXML[1]CallId=219-151652-0user.microapp.ToExtVXML[4]Date=3/18/2016user.microapp.app_media_lib..user.microapp.ToExtVXML[3]Language=EN;RNA=0;EWT=EWT5user.microapp.FromExtVXML[1]S1234567D|T1234567Juser.microapp.caller_inputTuser.microapp.FromExtVXML[2]WIS_PQuser.cvp_server_info10.182.30.104user.microapp.UseVXMLParamsNVoiceTRANSFER_SSTCONSULT_CALLHOLDUPDATE_CALL_DATASEND_DTMFDROP14162016-03-18T08:39:41.410ZACTIVE2016-03-18T08:39:41.410ZTRANSFER_SSTCONSULT_CALLHOLDUPDATE_CALL_DATASEND_DTMFDROP1410AGENT_DEVICE2016-03-18T08:39:54.532ZACTIVE2016-03-18T08:39:54.532ZACTIVE2900/finesse/api/Dialog/16800324PUT/finesse/api/Dialog/16800324","object":{"Update":{"data":{"dialog":{"associatedDialogUri":null,"fromAddress":"1416","id":"16800324","mediaProperties":{"DNIS":"1415","callType":"TRANSFER","dialedNumber":"2900","outboundClassification":null,"callvariables":{"CallVariable":[{"name":"callVariable1","value":"Y|Y|N|EN|2900"},{"name":"callVariable2","value":"S1234567D|T1234567J"},{"name":"callVariable3","value":"CC_Code_1_1_PQ"},{"name":"callVariable4","value":"219-151652-0"},{"name":"callVariable5","value":"1416"},{"name":"callVariable6","value":"EN"},{"name":"callVariable7","value":"2981"},{"name":"callVariable8","value":null},{"name":"callVariable9","value":null},{"name":"callVariable10","value":null},{"name":"user.microapp.ToExtVXML[0]","value":"application=EnableCSS"},{"name":"user.microapp.FromExtVXML[0]","value":"Y|Y|N|EN|2900"},{"name":"user.microapp.error_code","value":"0"},{"name":"user.media.id","value":"E72871800001000000000042691EB60A"},{"name":"user.microapp.isPostCallSurvey","value":"Y"},{"name":"user.microapp.metadata","value":"N|000|01|00|00|007675|GS,Server,V,interrupt"},{"name":"user.microapp.ToExtVXML[2]","value":null},{"name":"user.microapp.FromExtVXML[3]","value":null},{"name":"user.microapp.ToExtVXML[1]","value":"CallId=219-151652-0"},{"name":"user.microapp.ToExtVXML[4]","value":"Date=3/18/2016"},{"name":"user.microapp.app_media_lib","value":".."},{"name":"user.microapp.ToExtVXML[3]","value":"Language=EN;RNA=0;EWT=EWT5"},{"name":"user.microapp.FromExtVXML[1]","value":"S1234567D|T1234567J"},{"name":"user.microapp.caller_input","value":"T"},{"name":"user.microapp.FromExtVXML[2]","value":"WIS_PQ"},{"name":"user.cvp_server_info","value":"10.182.30.104"},{"name":"user.microapp.UseVXMLParams","value":"N"}]}},"mediaType":"Voice","participants":{"Participant":[{"actions":{"action":["TRANSFER_SST","CONSULT_CALL","HOLD","UPDATE_CALL_DATA","SEND_DTMF","DROP"]},"mediaAddress":"1416","mediaAddressType":null,"startTime":"2016-03-18T08:39:41.410Z","state":"ACTIVE","stateCause":null,"stateChangeTime":"2016-03-18T08:39:41.410Z"},{"actions":{"action":["TRANSFER_SST","CONSULT_CALL","HOLD","UPDATE_CALL_DATA","SEND_DTMF","DROP"]},"mediaAddress":"1410","mediaAddressType":"AGENT_DEVICE","startTime":"2016-03-18T08:39:54.532Z","state":"ACTIVE","stateCause":null,"stateChangeTime":"2016-03-18T08:39:54.532Z"}]},"state":"ACTIVE","toAddress":"2900","uri":"/finesse/api/Dialog/16800324"}},"event":"PUT","requestId":null,"source":"/finesse/api/Dialog/16800324"}}} 2016-03-18T16:21:41.220 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.641 +0800: CallControl : _processCall(): Process the dialog with id: 16800324, to extension: 2900, from extension: 1416, call state: ACTIVE, callType: TRANSFER 2016-03-18T16:21:41.240 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.661 +0800: CallControl : _processCall(): User's call state is: ACTIVE, user's state cause is: null 2016-03-18T16:21:41.272 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.693 +0800: Header : ------ Event queue is empty. ------ 2016-03-18T16:22:02.700 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:40:16.121 +0800: Header : Time Information - UTC: 'Fri, 18 Mar 2016 08:22:02 GMT'; Local Time: 'Fri Mar 18 2016 16:22:02 GMT+0800 (Malay Peninsula Standard Time)'

[dekwan]

Hi,

Sorry for not responding sooner. I didn't get a notification when you updated the log to this thread.

Can you attach the full files of the webservices log and client logs where you see Finesse getting the update from the cti server? I would like to see what Finesse is publishing when it gets the updated callvariable3 event. I need to pinpoint to see if it is a Finesse backend issue or a UI issue.

Thanx,

Denise

[jap_santi]

hi denise,

the log is huge.

can I email to you the file?

[dekwan]

Hi,

People have attached log files to their replies. If you click the "Use Advanced Editor" link on the upper right of the reply box, an "Attach" link will appear in the lower right.

Thanx,

Denise

[Hossain Ahmed Ashfaque]

Hi Denise,

Sorry for the delayed response. I attached the logs for you.

Thanks,

[Hossain Ahmed Ashfaque]

Hi Denise,

In the attached logs kindly look into the below log files only as it contains both the scenario i mentioned earlier.

Desktop-ClientLog.1001.2016-03-17T19-36-34.773

Desktop-ClientLog.1001.2016-03-17T19-38-36.441

Desktop-ClientLog.1001.2016-03-17T19-38-39.586

Desktop-webservices.2016-03-14T11-30-48.682.startup.log

Agent IDs are 1001 (ext 1415) and 1002 (ext 1410) caller number is 1416.

The call flow is 1416 to (1111 and VG convert it to 2900) VG  to CVP to agent (1001) to transfer to queue via CTI route point (275x) to CVP to Agent (1002).

1. No agent available in the new queue, caller hear the queue music after that agent become available and answered the call. This case agent call the Call Variable3 updated with the new Queue name.

The problem is

2. If the agent is available in the new queue and answer the call then Call Variable3 does not update and agent see Old queue name.

[dekwan · Accepted solution]

Hi,

I did an analysis of the logs you provided and came to this conclusion:

In the scenario where there are no agents available (#1) and call variable 3 gets updated correctly,

• Caller 1416 -> 1111 -> VG 2900: Original callId=16800318, callVariable3=CC_Code_1_1_PQ, callType=PREROUTE_ACD_IN
• Agent 1001 answers the call.
• Agent 1001 does a single step transfer to RP 2752 with no agents available: Consult callId=2130706446, callVariable3=CC_Code_1_2_PQ
• All calls are dropped for Agent 1001 due to the transfer
• Agent 1002 goes READY
• Agent 1002 gets a call. callId=16800319, callVariable3=CC_Code_1_2_PQ, callType=PREROUTE_ACD_IN

If you notice, when Agent 1002 goes READY and gets the call with the updated call variable 3, the call id is different than the original and consult call, and the callType is PREROUTE_ACD_IN instead of TRANSFER. It seems like UCCE treats the call to Agent 1002 as a queued call and loses the transfer details.

In the scenario where Agent 1002 is available (#2) and call variable 3 doesn't get updated correctly,

• Agent 1002 goes READY
• Caller 1416 -> 111 -> VG 2900: callId=16800274, callVariable3=CC_Code_1_3_PQ, callType=PREROUTE_ACD_IN
• Agent 1001 answers the call.
• Agent 1001 does a single step transfer to RP 2752 and agent 1002 is available. Consult callId=2130706446, callType=AGENT_INSIDE
  • Original callId=16800274 has callVariable3=CC_Code_1_3_PQ
  • Consult callId=2130706446 has callVariable3=CC_Code_1_2_PQ
• After the transfer is complete, the original call with id of 16800274 survives. As a result, all of the call variables from that call survives (callVariable3=CC_Code_1_3_PQ), callType=TRANSFER

If you notice, in this situation, the consult call is the one that gets its call variable 3 updated. Since the original call (almost) always survives, the updated call variable 3 gets lost.

UCCE is sending Finesse the events like this, so Finesse is just reading in these events and processing it. There isn't anything Finesse can do in this situation. If it is a problem for you, you have to chase the issue with the UCCE/PCCE team.

I have attached my notes (copies of log snippets from the webservices logs) to come to this conclusion.

Thanx,

Denise