Attended Call Transfer issue

[vbashin]

We have an issue when trying to execute our virtual agent-driven attended transfer operation.

Please see the attached Word-file with the question.

With the CONSULT_CALL command sent to Finesse, we do NOT get any notifications on the original call dialog.

We are getting the ACTIVE notifications only for both participants  of the new, consult call dialog.  

[dekwan]

Hi,

Have you tried to use the Finesse out of the box agent desktop to reproduce the scenario? Do you see the same issue where there isn't a notification on the original call dialog?

The logs that were provided seems to be on the client side. Take a look at the Finesse webservices logs to see if the Finesse server is sending those notifications. If not, is there an error? If not, take a look at the CCE/CCX CTI server logs.

Thanx,
Denise

[vbashin]

Thanks Denise.
Could you please send me the info on how to collect the CCE/CCX CTI server logs?

Regards,
VB

[dekwan]

Hi,

For CCX, get the Cisco Unified CCX Engine logs: https://community.cisco.com/t5/collaboration-voice-and-video/collecting-uccx-logs-from-cli/ta-p/3336274

For CCE, get the CTI Server logs: https://community.cisco.com/t5/collaboration-voice-and-video/how-to-collect-logs-for-cisco-tac-with-the-unified-system-cli/ta-p/3116267

Thanx,

Denise

[vbashin]

Thanks Denise

[vbashin]

Hi Denise,

Finally we coordinated with the customer so they agreed to collect the Finesse WebServices logs

Now they are asking what features logging and at what level should be enabled in the Webservices so it was sufficient for collecting the "right" logs. 

They say there are a lot of debug options on Finesse and some are dynamic and some require restart. 

Could you please advise?

Thanks,

Vladimir

[dekwan]

For the Finesse webservices logs, the default levels are sufficient. As for the CTI server logs, I'm not sure because that is not my area of expertise.

Were they able to reproduce the issue with the Finesse out of the box desktop?

Thanx,
Denise

[vbashin]

Denise, thanks for the rapid reply -

it seems the Finesse logging settings at a  customer site have been set to some non-default level so the log does not capture the xmpp notifications sent to our virtual agent.
So, what should be enabled to mimic the default logging level?

Regarding the test with the Finesse out of the box desktop - at this point we are not allowed to run this test, unfortunately

[dekwan]

Hi,

As far as I know, the Finesse webservices logs doesn't actually have trace levels. I have seen it from time to time where the logs don't contain much information (although there is SOME logging). The only solution to that issue that I know of is to restart the Cisco Finesse Tomcat.

Thanx,

Denise

[vbashin]

Hi Denise,

Finally, we were able to rerun the test and collect the Finesse Web Service logs (attached)

So, we have the initial, main dialog 50344168 between a caller and the agent 1335185089

We are executing a CONSULT CALL on dialog 50344168 between the agent 1335185089 and the agent 1335185090

The consult call dialog 33602515 get created

Note that on any of those two dialogs we didn’t get the notification with the CallType : CONSULT_CALL and with the allowed actions listing the TRANSFER command. -  I wonder why?

We are trying to execute the TRANSFER command for the agent 1335185089 on this main dialog 50344168 and getting the error.

Please advise why we are not allowed to complete the attended transfer. 

[dekwan]

Hi,

I am not seeing the scenario you are describing in the logs. This is what I see:

1. The first occurrence of 50344168 is where there is a request to TRANSFER the dialog by user 47483714:

0032260412: 10.35.183.171: Dec 03 2018 09:55:50.665 -0700: %CCBU_http-apr-8082-exec-5-6-REQUEST_START: %[method_name=PUT][parameter_name={ }][resource_name=/Dialog/50344168][usr=47483714]: Request start
0032260413: 10.35.183.171: Dec 03 2018 09:55:50.667 -0700: %CCBU_http-apr-8082-exec-5-6-API_REQUEST: %[REQUEST_URL=Dialog/50344168][agent_id=47483714][requestId=null][request_method=dialog.PUT][request_parameters= requestedAction:TRANSFER targetMediaAddress:1335185089]: Request from client to webservice api

2. At this point, user 47483714 is already on two calls, 33602515 and 50344168. 33602515 is NOT the consult call:

0032260415: 10.35.183.171: Dec 03 2018 09:55:50.667 -0700: %CCBU_http-apr-8082-exec-5-7-Agent.getCalls: {Thrd=http-apr-8082-exec-5} For agentId=47483714, get callIds=[33602515, 50344168].

3. The only available action for dialogId 50344168 is TRANSFER_SST, CONSULT_CALL, HOLD, UPDATE_CALL_DATA, SEND_DTMF, DROP. TRANSFER is not one of them:

0032260427: 10.35.183.171: Dec 03 2018 09:55:50.668 -0700: %CCBU_COMMAND_POOL-17-worker-111-6-FINESSE ALLOWED ACTIONS: %[extension=1335185089][finesseActions=[TRANSFER_SST, CONSULT_CALL, HOLD, UPDATE_CALL_DATA, SEND_DTMF, DROP]]: Actions allowed by Finesse

The logs don't show when the calls 33602515 & 50344168 were started, so I can't really comment anything other than the fact that 50344168 is a fresh/new call where you need to do a CONSULT_CALL first before transfering.

This is an example of the process on doing a call transfer:

1. There is an active dialog with ID 123456 between the caller and AgentA. Both parties are talking to each other.

2. Using AgentA's credentials, it calls the API against dialogId 123456 with the action of CONSULT_CALL to lets say AgentB. Consult call with dialogId 789012 gets created. The original Call with dialogId 123456 is still ACTIVE, but AgentA's participant state goes HELD/HOLD (I forgot which terminology).

3. AgentB answers the consult call (dialogId 789012) and AgentA and AgentB are talking. So now, AgentA has two calls under their dialog list, 123456 and 789012. AgentB just has one, 789012.

4. AgentA wants to transfer the original call to AgentB. Using AgentA's credentials, it calls the API against the original call, dialogId 123456 with the action of TRANSFER. As a result, 

• AgentA gets dropped off of both dialogs 123456 and 789012
• AgentB gets dropped off of the consult call 789012
• AgentB gets added to the original call 123456

I hope the above explanation helps.

Thanx,

Denise

[vbashin]

Denise , thank you very much for the rapid reply!

Attached please find the Finesse log capturing the initial call setup and consult call

With that - that's how i understand your AT call flow:

This is an example of the process on doing a call transfer:

1. There is an active dialog with ID 123456 (i.e. 50344168) between the caller and AgentA. Both parties are talking to each other.
2. Using AgentA's credentials, it calls the API against dialogId 123456 (i.e. 50344168) with the action of CONSULT_CALL to lets say AgentB. Consult call with dialogId 789012 (i.e. 33602515)  gets created. The original Call with dialogId 123456 (50344168)  is still ACTIVE, but AgentA's participant state goes HELD/HOLD (I forgot which terminology).
3. AgentB answers the consult call (dialogId 789012 - aka 50344168) and AgentA and AgentB are talking. So now, AgentA has two calls under their dialog list, 123456 (50344168) and 789012.( 33602515)  AgentB just has one, 789012 (33602515).  So to me 33602515 is  the consult call
4. AgentA wants to transfer the original call to AgentB. Using AgentA's credentials, it calls the API against the original call, dialogId 123456 (50344168) with the action of TRANSFER. As a result, 

AgentA gets dropped off of both dialogs 123456 (50344168)  and 789012 (33602515)  AgentB gets dropped off of the consult call 789012 (33602515) AgentB gets added to the original call 123456 (50344168)

Am I still missing something here?

Thanks again,

VB

[dekwan]

Hi,

Now that I see the logs of both calls from the beginning I have a better picture.

1. DialogId 50344168 is established and there is a request to do a CONSULT_CALL is.

0032257516: 10.35.183.171: Dec 03 2018 09:55:28.651 -0700: %CCBU_http-apr-8082-exec-24-6-API_REQUEST: %[REQUEST_URL=Dialog/50344168][agent_id=47483714][requestId=null][request_method=dialog.PUT][request_parameters= toAddress:1335185090 requestedAction:CONSULT_CALL targetMediaAddress:1335185089]: Request from client to webservice api 

2. Finesse sends the request to the CTI Server

0032257532: 10.35.183.171: Dec 03 2018 09:55:28.684 -0700: %CCBU_COMMAND_POOL-17-worker-109-6-MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :31775968 , connectionDevId: 1335185089, callID: 50344168, dialedNumber: 1335185090, agentInstrumentTag: 1335185089][cti_message_name=ConsultCallReq]: Message going to the backend cti server

3. But when CTI Server creates the call, it is not a consult. Therefore, Finesse doesn't associate the two calls together, making them look like two independent calls. As a result, the option of "TRANSFER" is not available:

0032257537: 10.35.183.171: Dec 03 2018 09:55:28.935 -0700: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_event_read_time=1543856128935][cti_message=CTIBeginCallEvent [peripheralId=5000, connectionDeviceIdType=0, callId=33602515, connectionDeviceId=1335185089, ani=1335185089, dnis=null, dialedNumber=1335185090, callType=10, callVariable1=null, callVariable2=null, callVariable3=null, callVariable4=null, callVariable5=null, callVariable6=null, callVariable7=null, callVariable8=null, callVariable9=null, callVariable10=null, callWrapupData=null, routerCallKeyDay=-1, routerCallKeyCallId=-1, routerCallKeySequenceNum=null, ctiClientSignature=[Finesse]]CTIBeginCallEvent [ invokeID=null, cti_sequence_id=31810968, msgID=23, msgName=BeginCallEvent, deploymentType=CCE]]: Decoded Message to Finesse from backend cti server

It is returning back callType of 10, and when you look at the documentation, that is not a consult: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_11_6_1/Reference/Guide/ucce_b_cti-server-message-reference-guide/ucce_b_cti-server-message-reference-guide_chapter_0110.html#reference_CC360...

Now why is CTI returning back callType of 10? You will need to open a TAC case and have them take a look at it.

Thanx,

Denise

[vbashin]

Thank you very much, Denise -



I'll talk to our PS team so they could open the TAC case and have them take a look at it.

[dekwan]

Hi,

If you can, I would suggest trying this out using the Finesse out of the box desktop. The Finesse desktop uses the same APIs. It would be good to see if you see the same behavior. I would compare the webservices logs with the ones you provided and the ones from the out of the box desktop to see if the difference.

Thanx,

Denise