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.

[mario.covarrubias]

Hi Denise,

Thank you for your quick response. We will follow your advice and verify the results.

If there are more issues I'll contact you again.

Thanks,

Mario

[mario.covarrubias]

Hi Denise,

We have been trying to connect via Pidgin but have not been able to do so. We followed the instructions established for Pidgin in Finesse specification, but keep getting the user as Not Authorized.

Maybe it is some of the connection parameters we have specified, and I believe it could be the Domain, because the username ends up like this: user@domain/ this "/" is what makes us think that we are not specifying that value correctly.

How do we specify the domain correctly? In other words: which would be an example of fully-qualified domain name of the Cisco Finesse server? Do we need to add /finesse so the Domain is specified as domain/finesse?

Are we correct in our assumptions for this problem?

Another related question: Can you give us advice in how to see the Finesse logs?

Thanks again for all your help.

Mario

[dekwan]

Hi Mario,

Here is an example of my system:

I hope this helps!

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

Again thank you very much for you response, you have been really helpful.

Following the example you gave us, we were able to connect via Pidgin in order to view the messages in the XMPP Console. Now, when we tried to do a User - Sign in to Finesse, we get the following error message in Pidgin:

Do you have any idea what does this error means and what do we need to do to solve it?

Thanks again for all your help.

Mario

[dekwan]

Hi Mario,

I'm glad that you were able to connect via Pidgin.

As far as the error, if you take a look at the Sign In to Finesse section of the Developer guide:

Are you sure the device is working correctly? Is it associated to the PG? I found documentation for PCCE 9.0 (that applies for 10.5) on how to add phones: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/pcce/pcce_901/installation/guide/PCCE_BK_IBC40C6F_00_installing-and-configuring-pcce/PCCE_BK_ICC40C6F_00_installing-and-configuring-pcce_chapter_0111.html#PCCE_TK_C21DBA2D...

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

Thanks again for your help, I will check the devices status with the team in order to confirm that they are working correctly.

If anything comes up I'll be in contact.

Thanks,

Mario

[mario.covarrubias]

Hi again Denise,

We have tried using the SIGN IN TO FINESSE API with 3 differente test users and extensions, obtaining different results:

User 1: The one reported previously, which results in the Invalid Device error. We are looking for a configuration issue because apparently the IP Phone is added to the PCCE.

User 2: The API apparently works correctly, because the XMPP Console shows the agent info, with the status NOT_READY.

User 3: We don't kno if the API actually does something... the result give in the XMPP Console is just a ping call.

Do you know why could we be getting this result with User 3?

Thanks again,

Mario

[dekwan]

For User 3, the ping calls happen for all the agents to make sure the connection is active. If that is all you are getting, Pidgin is not receiving any XMPP notifications. Pull the Finesse Webservices logs and find the API request that you made to sign in. See if it sent any XMPP events. If so, there might be a configuration issue on the Pidgin side. If not, are there any errors?

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

Thanks for your reply. We continued the test and now are able to connect with User 3 also. The only test user that remains with a problem is the User 1. We are still checking configuration...

In other issue, I would like to return to the topic about real-time events in Finesse. You might remember that we need to know when the following events occur:

• New call ringing in an extension. When a new call rings, we must send the call information to the third party application.
• Ending of a call that wasn't answered.
• Call entering a queue.

At first, I thought we would be in the browser based application scenario, however, after verifying with the developers team, apparently we will use a server based application, connecting via XMPP (similar to Pidgin). The question here is: Do you have any recommendation of a XMPP library that we could use as part of our server based application? Apparently there are different options, so we would like a recommendation of someone with more experience in the matter.

Thanks again for all your help.

Mario.

[dekwan]

Hi,

Finesse uses the Smack library: Ignite Realtime: Smack API to connect via XMPP. So that would be my recommendation.

Thanx,

Denise

[mario.covarrubias]

Hi again Denise,

I would like to make another question:

When you use the following APIs:

• Dialog—Initiate a Single Step Transfer
• Dialog—Create a New Dialog (Make a Call)
• Dialog—Take Action on Participant - ANSWER
• Dialog—Take Action on Participant - DROP
• Dialog—Make a Silent Monitor Call
• Dialog—Make a Barge Call

Is there a change of status for the Agent / Supervisor? We have checked the supported state transitions in the User - Change Agent State API, but it's not really clear for if there is a change of state and what state would the Agent/Supervisor have if the APIs executed correctly.

Thanks again,

Mario

[dekwan]

Hi Mario,

Some of those APIs trigger an agent state change. This is a pass through from the deployment (UCCE/UCCX). I would suggest using the API and just seeing which one causes a state change. The easiest thing to do is to use the Finesse out of the box UI and play around with it and see the expected behavior. I don't remember the state changes for all of these off the top of my head.

Thanx,

Denise

[mario.covarrubias]

Hi again Denise.

Looking at your comment about events in the /finesse/api/User/<id>/Dialogs node, with <event> tag POST for new call and <event> tag DELETE for a call terminated, you mentioned: “In this same event, the <state> tag value would be ALERTING. This means that the call ended and it was still ringing.”

Looking at the CTI Event Mappings for Dialog and Participant States, it is shown that when the event method is DELETE, the Dialog State is DROPPED. Is it really possible to find a Dialog State with value ALERTING when a call is terminated?

Another related question, the CTI Event Mappings specify that, when the caller drops the call (CALL_CONNECTION_CLEARED), the event method is PUT, while only the Caller state passes to DROPPED (leaving the Dialog and Agent state as ACTIVE). The question here is, does this event later go through the END_CALL_EVENT to remove the call so we can get the DELETE event method? I ask this in order to know if the DELETE state can help us to determine when the call is terminated, no matter who terminated it (agent or caller).

One final question. In the Dialog object, Is there a way to identify which participant is the caller and which participant is the recipient?

Thanks againt for all your help.

Mario

[dekwan]

Hi Mario,

Is it really possible to find a Dialog State with value ALERTING when a call is terminated?

Sorry, I meant participant state is ALERTING, not dialog state.

Another related question, the CTI Event Mappings specify that, when the caller drops the call (CALL_CONNECTION_CLEARED), the event method is PUT, while only the Caller state passes to DROPPED (leaving the Dialog and Agent state as ACTIVE). The question here is, does this event later go through the END_CALL_EVENT to remove the call so we can get the DELETE event method? I ask this in order to know if the DELETE state can help us to determine when the call is terminated, no matter who terminated it (agent or caller).

Yes, there will always be an END_CALL_EVENT after the CCC event. As you stated, the END_CALL_EVENT sends the DELETE event.

Thanx,

Denise

[mario.covarrubias]

Thanks again Denise,

Do you know something about the other queston I asked?

In the Dialog object, Is there a way to identify which participant is the caller and which participant is the recipient?

Thanks,

Mario