Web Services with Finesse 10.5 and UCCE Packaged

[Luis Enrique Perez Trujillo]

Hi, We installed a new Packaged UCCE 10.5 for 20 agents, We need communicate the UCCE with third party through Web Services, it's our first installation and I don't know very well the solution when integrate Web Services.

In the implementation I have Finesse 10.5 for both sides.

Can you help me with any experience or documentation?

I hope your comments.

[dekwan]

Hi,

Sorry, I guess I glanced over that question earlier. There isn't a general 100% fool-proof way to determine who is the caller and who is the recipient. If it is a direct call from A to B, then you can use the fromAddress and dialedNumber, but when you get into the transfers and conferences, this logic doesn't hold.

Thanx,

Denise

[mario.covarrubias]

Hi,

That's what I thought when we reviewed de Dialog object... I'm not 100% sure if we will need to identify that, but I wanted to know if there was a way to do it.

Thanks again,

Mario.

[mario.covarrubias]

Hi again,

I forgot to ask something else...

You already told me that Finesse does not have an API or event to detect when a call enters the Queue but, do you know if there is a way to get a list of the phone numbers that are in the Queue?

The purpose is to know if we can obtain a list of the call that are waiting to be attended in the Contact Center.

Thanks again,

Mario

[dekwan]

Hi,

Nope there is not an API for that. I am not 100% sure, but I don't think that PCCE has that either.

Thanx,

Denise

[mario.covarrubias]

Hi:

I hope you can help us with something.

We have been running some tests simulating calls in order to confirm the good execution of Finesse APIs. We tried to simulate a cycle with the following:

1. Agent Login (User—Sign In to Finesse)
2. Make a Call (Dialog—Create a New Dialog (Make a Call))
3. Answer a Call (Dialog—Take Action on Participant with ANSWER as <requestedAction>).
4. Finish a Call (Dialog—Take Action on Participant with DROP as <requestedAction>).

Apparently everything goes OK but, after the call is dropped, if we try to check the Dialog information of that call, we are not able to find the Dialog object.

We tried using User—Get List of Dialogs, from an user who was participant in the call, but Finesse returned no dialogs for that user.

We also tried running Dialog—Get Dialog giving the corresponding dialogId that we obtained while the call was being executed, but in this case Finesse responded with a 404 Not Found error.

We noticed that after a Dialog is dropped, apparently its information dissapears after a few minutes…

Do you know what could be happening here? Is this normal? Are we missing something?

Note: After a call is dropped, we need to calculate how much time it lasted since it was answered by the agent, but we can’t do that if we are not able to find that dialog.

Thanks,

Mario.

[mario.covarrubias]

Hi,

A little update in the situation explained before...

At the beginning we thought that the steps enlisted, which used Finesse APIs, were finishing correctly, but doing the same test and monitoring XMPP messages, we found out that in the following API:

• Answer a Call (Dialog—Take Action on Participant with ANSWER as <requestedAction>).

An error 4047 - INVALID_ACTION ANSWER occurs (see image) and the Dialog goes to state FAILED

Soon after this error happens, another notification is received, with an event DELETE for the Dialog. So now we have confirmed that the Dialogs are indeed being deleted, but we don't know what causes the error...

Do you know what could be causing this error (4047 - INVALID_ACTION ANSWER)?

I couldn't find this error in Finesse dev_guide. Any suggestions??

Thanks,

Mario

[dekwan]

Hi Mario,

Apparently everything goes OK but, after the call is dropped, if we try to check the Dialog information of that call, we are not able to find the Dialog object.

We tried using User—Get List of Dialogs, from an user who was participant in the call, but Finesse returned no dialogs for that user.

We also tried running Dialog—Get Dialog giving the corresponding dialogId that we obtained while the call was being executed, but in this case Finesse responded with a 404 Not Found error.

We noticed that after a Dialog is dropped, apparently its information dissapears after a few minutes…

Do you know what could be happening here? Is this normal? Are we missing something?

That is correct behavior and by design. Once the call is dropped, the Get Dialog will indeed return a 404 because it is no longer there (it was deleted). The user's list of dialogs also won't have it because the user is no longer on the call.

Note: After a call is dropped, we need to calculate how much time it lasted since it was answered by the agent, but we can’t do that if we are not able to find that dialog.

Can't you just use the agent's state time? When the call is ringing on the agent's phone, the agent's state is RESERVED. When the agent answers, it will go to TALKING (Or hold). When it is dropped, it will go back to READY. So can't you just calculate the time the agent is in hold or talking?

Do you know what could be causing this error (4047 - INVALID_ACTION ANSWER)?

This error is exactly what it sounds like. For the dialog with id of 50623931, the extension 11822 cannot answer the call. Did the call drop before extension 11822 answered? Is extension 11822 part of the call? Take a look at the webservices logs. Search for dialog id 50623931 and go down the whole flow to see what is happening.

I couldn't find this error in Finesse dev_guide.

Hm, I guess it isn't in the developer guide. Strange.

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

I think we found out why the 4047 - INVALID_ACTION ANSWER was happening… After reviewing the data sent to Finesse in the Dialog—Take Action on Participant, we confirmed that the value that was being sent in the <targetMediaAddress> was the caller number, when we are supposed to specify the extension of the recipient (Note: I want to clarify that we are trying to test an AGENT_INSIDE call, making a call from one agent’s extension to another agent’s extension).

Now the problem is that we get an Unauthorized error, which Finesse defines its causes as:

Unauthorized (for example, the user is not yet authenticated in the Web Session).

The user is not authorized to use the API (for example, an agent tries to use an API that only a supervisor or administrator is authorized to use).

The curious thing is that both agents (caller and recipient) are signed in to Finesse with an extension associated to them, so we don’t really know why this error could be happening.

After the error occurs, the Dialog FAILS and gets DROPPED, finishing with DELETE again, so the call is not completed.

Any ideas why could the Unauthorized error be happening?

Thanks,

Mario.

[dekwan]

Hi Mario,

Can you send me the webservices and realm logs for this scenario?

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

I attach now the file Desktop-webservices.2016-08-24T10-43-39.275.log, which represents the webservices log for the tested scenario

We couldn't find any realm log with records in the same time that are described in the webservices log...

To complement the information, I explain the following:

• We are trying to do an AGENT_INSIDE call, doing a phone call from one extension (agent) to another extension (agent).
• The agents we are using for this scenario are:
  • Caller:
    • Username: CCASTRO
    • AgentID: 348
    • Extension: 11822
  • Recipient:
    • Username: amochis1
    • AgentID: 3127109
    • Extension: 11821

Apparently the log shows failed LOGIN and LOGOUT commands for agentID 3127109, but we are not sure why are these errors happening.

Thanks,

Mario

[dekwan]

This was the only log file? This doesn't seem right... Were these logs filtered? Because I see time gaps between the different log lines. I am looking for the webservices logs for the make call and answer.

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

Sorry for the late response... The logs I sent you were the only ones that we found. We also believed it was strange...

Apparently we were able to complete the AGENT_INSIDE call cycle, we had to change the user connected to extension 11821.

Now we are trying to simulate a call originated from outside, with an agent as recipient. We will probably need help sometime in the future so I will be contacting you.

Thanks again,

Mario.

[mario.covarrubias]

Hi Denise,

Excuse me, we are facing one issue while trying to use de Dialog—Make a Silent Monitor Call API.

We have 2 phones connected, one to an agent and the other to a supervisor. Both are part of the same team.

When we simulate a call and it enters to the agent extension, we try to execute the Silent Monitor from the supervisor's extension, however, we receive the following error.

Finesse is telling us that the READY state is not valid for silent monitor. The question here is... which state is valid for silent monitoring? What do we need to do in this case?

Thanks,

Mario

[dekwan]

Hi Mario,

Per documentation under Platform-Based Differences: https://developer.cisco.com/media/finesseDevGuide4.1/CFIN_RF_DD5F21C5_00_dialog-make-a-silent-monitor.html, supervisors can only silent monitor when they are in NOT_READY state.

Thanx,

Denise

[mario.covarrubias]

OK... I think we missed that condition in the API specification...

And we thought that we read everything explained in the Finesse Guide for this matter.

Thanks again for your help

Mario