Differentiating between agent transferring and one receiving the transfer

Platform API Java SDK
1

I am trying to workout the best way to determine if the call received is a normal call or part of consult transfer?

I have notificed that there is a consultParticipantId populated for the original agent but this is not populated for agent recieving the transfer.

Also, the original agent performing the transfer has the following set.

"attributes":{
"consultInitiator":"true"
},

Is any of these something I can rely on or is it any better recommendation on how to check if the received call is a normal call or a transfered one?

2

@tim.smith any idea?

3

I just tested making a consult call and then used GET /api/v2/conversations/calls during the consult. The consultParticipantId participant was set on both the user and consulting participant to indicate the GUID of the consulted participant.

4

You mean you have consultParticipantId set on both agents? (i.e. one initiating the transfer as well and come receiving the transfer via the queue)?

I don't seem to have the consultParticipantId set for one receiving it. ("CorrelationId":"1dede1eb-eef0-4996-9ea4-b6a8a1457e38")

5

@tim.smith

So looks like consultParticipantId is not set on the receiving agent until the acd state is disconnected and agent state is connected. At this stage, the receiving agent also has a consultParticipantId set.

Another question-when in middle of consult transfer and original customer disconnects, the consultParticipantId is removed from all participants (which makes sense since it is not a consult transfer anymore). However, it also take way the consultInitiator attributes from the agent performing the transfer (which was set initially)

I would think that the consultInitiator is still a consult initiator although the customer might have disconencted? Is this a desired behavior or a bug?

If a desired behaviour, how can I know out of the two, who initiated the call? ("CorrelationId":"3dd4936c-1650-45fb-98e6-b1442e89bf89" (does not have consutlInitiator set), "CorrelationId":"4c49ac83-244c-4897-a4a1-f2543a788e2a", "CorrelationId":"9bd2bf66-cc74-42db-a0a1-eabdeed7d688")

6

@tim.smith @anon84847021 any suggestions on this?

7

I've been discussing this with the dev team, and there's not currently any data available after the conversation has ended to indicate that a call was a consult. The best you can currently accomplish is to look for overlapping segments. You'll know which parties were involved and that the first participant invited the second, but you won't be able to tell if it was a consult or conference. However, keep in mind that you can't conference ACD calls, so if there are more than 2 active participants at one time and any of them have purpose=agent, it must have been a consult transfer.

If you can provide a use case for why you need this information, I can submit an enhancement request with your use case.

8

Not sure what you mean by overlapping segments? Are you able to explain in bit more detail please?

How would i know which parties were involved and the first participant invited the second? If I knew this this, it might help solve some of my problem :slight_smile: (Or do you mean I would know the order based on, the order they are on the participants list?)

I don't think checking for two active participant and one of which has purpose=agent would work as we might also have a customer who is connected? Or am I missing something?

UseCase:
My usecase in based on some variations of consult transfer and is most likely due to the our UI having a single layer of CTI toolbar controls in our custom CRM application.

When agent1 receive a call on Queue1 from a customer and performs a consult transfers to another queue (Queue1), It end up with agent2.

From agent1's perspective:
When in middle of the consult transfer, the customer drops/disconnects. At this stage our implementation know that the customer has disconnected and updates the UI so that the agent1 cannot alternate between the customer and agent2.
All good here.

From agent2's perspective:
Agent2 receives the calls from agent1 (but also has a customer participant on the notification message). As above when the customer drops/disconnects. At this stage our implementation know the customer has disconnected and tries to update the UI.

However, for agent2 it should not matter that customer has disconnected as for agent2 the "customer" should actually be the agent1 and until agent1 is connected, the call should still be connected.

So when the customer disconnects, I am trying to check if the call was a consult transfer and if so, ignore the main customer disconnect.

In order to differentiate, one way I was thinking was to check if the call was a transfer consult or not. (How does the PureCloud web app handle this?)

Any suggestions will be appreciated.

9

Take a look at the screenshot below. See where there are three segments that overlap? That means that the participants were all active in the conversation at the same time. You can determine this programmatically by comparing the startTime and endTime properties of each participant.

The list of participants on the conversation defines the parties that are involved. Take the call below. There are three overlapping participants. One is a customer, so I know they didn't add anyone to the call. In this case, the other two are an agent and another external call. I know the agent added the external call for two reasons:

  1. An external call couldn't add an agent
  2. The agent was in the conversation first, so they had to have added the third call

In the case that an agent consults with another agent, the agent that joined first had to have invited the agent who joined later; the second agent couldn't have invited the first agent to join before they were in the conversation.

1 Like
10