Finesse displays 'Number of Participants'

[dannoofWI]

We just upgraded to UCCX v12. Some of our agents displays are showing the number of participants in a call as circled in Attachment 1. The rest of the agents display the calling number as shown in attachment 2. I am having difficulty in determining what controls that particular part of the display.

[dannoofWI]

Sorry attachment 1 was not included.

[TimoV]

If there are multiple parties in a call (conference), the numbers are shown the way seend in Attachment 1. For calls with 2 parties, the number is shown directly, as seen in Attachment 2

[dannoofWI]

Thank you TimoV for the reply, but in Attachment 1 there are only 2 participants.

[TimoV]

Yes, but those two are the parties other than the agent. So in attachment1, there's been 3 parties in the call, the agent and the 2 shown.

[dannoofWI]

The reason this is brought up is when being Silent Monitored the agent sees there are more than 2 participants.
I am right now in a call with my Finesse screen open showing only the originating number even though I am being Silent Monitored. So there must be something different between the two desktops.

[dekwan]

Hi,

When calls are being silent monitored, there are three parties on a call. As TimoV stated, calls with 3 or more parties will be like attachment1 and 2 parties will be like attachment2.

I would suggest looking at the client logs for both scenarios to see the dialog notifications and compare. Are both scenarios 2 parties? Is it 3? Who is that 3rd person?

Thanx,

Denise

[Anthony Holloway]

I can reproduce this in devnetsandbox.cisco.com version 12.5 with the following simple scenario.  I think it might be a bug.

[david.macias]

I'm trying to understand what is being asked. One question seems to be if the agent sees 2 participants on a call when they know they only have one person they are talking to it means they are being silent monitored. If this is the case this doesn't seem to be correct. The whole point of silent monitoring is to see agents in their natural habitat. @Anthony Holloway is that what you tested?

david

[Anthony Holloway]

Mine is simply reproduced when one script redirects to another (technically the script redirects to a trigger, but you know what I mean).

The second phantom participant is the CTI Port from the first leg/segement.

E.g.,
Caller at 6001 calls trigger 6344 and connects to CTI port 8006001. That first script call redirects to trigger 6345 and a new CTI Port is picked, call it 8006002. When the call arrives at the Agent, it shows 2 participants, one being 8006001 and the other being the caller 6001.

Anyone can recreate this in devnetsandbox.cisco.com. I was using the 12.5 one, but I hear it happens in 12.0 too.

EDIT: I should mention that there was auto recording enabled on the Agent line, so I removed it and the behavior remained the same.  If I instead switch to a single script solution, no redirects, the participants looks fine.  It's only when you redirect from one script to the other.

[dekwan]

Hi @Anthony Holloway ,

Thank you for reproducing this issue. Let me take a look into this and discuss this with Finesse team.

Thanx,

Denise

[Anthony Holloway]

Awesome! Thanks!

[Anthony Holloway]

Did you find anything out?

[dekwan]

Hi,

Sorry. Took me a while to chase this down, then I went on PTO.

It is most likely an issue on the CCX side. They asked me to open a bug (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu95441) and they are looking into it.

Thanx,

Denise

[tannerezell]

I can confirm this isn't a JTAPI issue. As far as I can tell, this appears to be a bug in the CTI engine used by finesse. The UI is receiving information that it should have two participants plus the agent, which obviously is wrong.

Essentially the first CTI Port from the initial call shows dropped but the second CTI Port (after the call redirect) remains active, according to Finesse. However this is not accurate according to the JTAPI subsystem which shows the CTI Port with no active connections or calls.

This leads me to assume the issue exits in the CTI engine underlying finesse, and quite possible a race condition could be causing the issue, likely in the call observers and event handling. 

This is all a guess, I haven't dug into that system and I'm probably not going to at this point either. I can only assume the following is happening (all assumptions):

1. Initial call comes in, JTAPI Call Contact with the first CTI Port is created, an event is fired when the caller is accepted, caller is connected to CTI Port

2. through script logic, the caller is redirected, the first CTI Port disconnects and the disconnect event message is received by the handler

3. same call contact is now connected to the new CTI Port and a new event is fired, call added to contact. I don't think the disconnects are properly being processed.a 

3a. steps 2-3 can repeat as many times as you want

4. the caller will see the CTI Ports involved as part of the participants in finesse., despite there being no calls or connections on any of the CTI Ports.

I suspect the handler for these messages stops processing after the first disconnect event.

You can chain these for fun and to terrifying effect: 

No workaround at the script level is possible I'm afraid :(. What a disaster.