Legacy Dev Forum Posts

andygunther | 2016-10-05 20:23:31 UTC | #1

I'm having a hard time finding a method I can use to pull the wrap up code name from the Wrap Up Code Id that I get from a segment of a conversation. Can someone point me in the right direction?

Also, can someone please advise what the QueueId is that I can pull from a segment? I'm trying to find the ACD queue that a call was handled in, and I'm not sure if I can't get it because the test data I'm working with doesn't have any of those calls, or if trying to use that QueueId to retrieve the Group is the wrong approach.

Thanks!

tim.smith | 2016-10-05 20:51:30 UTC | #2

Wrap up code resources are in the Routing category. Use GET /api/v2/routing/wrapupcodes/{codeId} to retrieve the details (name) of the wrap up code.

To find out what queue a call was in, look for participants with the purpose acd. The segments will contain a queueId property. Details about the queue can be retrieved from GET /api/v2/routing/queues/{queueId}. If you just need the name of the queue, it's set to the participantName property.

Here's an example queue participant.

{ "participantId": "43adf9e4-d48e-456d-8337-44823e6d17aa", "participantName": "Queue 1", "purpose": "acd", "sessions": [ { "mediaType": "voice", "sessionId": "4619ab38-43ee-4b27-bebc-4f10e2618265", "ani": "tel:+13172222222", "direction": "inbound", "segments": [ { "segmentStart": "2016-09-01T19:24:34.843Z", "segmentEnd": "2016-09-01T19:24:34.847Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "segmentType": "delay", "conference": false }, { "segmentStart": "2016-09-01T19:24:34.847Z", "segmentEnd": "2016-09-01T19:25:01.971Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "disconnectType": "peer", "segmentType": "interact", "conference": false } ] } ] }

andygunther | 2016-10-05 20:50:38 UTC | #3

Thanks for those - that's what I needed!

andygunther | 2016-10-05 20:53:41 UTC | #4

One other question - what else can appear in ParticipantName? I ask because I have SegmentTypes of Ivr with a value in that property.

tim.smith | 2016-10-05 21:04:03 UTC | #5

The participant name is akin to eic_remotename in CIC; it can be many things and depends on the context. Ultimately, it's the display name for whatever the participant was.

andygunther | 2016-10-06 00:00:48 UTC | #6

But can you set it to be something in Architect? Could it be an IVR name? I don't see how the IVR segment could have a Participant name.

tim.smith | 2016-10-06 13:45:04 UTC | #7

It looks like participantName on the ivr participant is being set based on a RWP lookup of the DNIS. If you need a more definitive answer, let me know and I can check with the dev team and see what logic is applied to the value.

andygunther | 2016-10-06 14:03:27 UTC | #8

Nah, that's ok, thanks! I'm just trying to get my head around how I can tell definitive things about a call by looking at the Segments. Like, this was a Queue call. This one abandoned. This one had ACD Wait Time, this one had handle time, etc.

Most of it seems pretty straightforward - but I'm struggling to tell the difference in a few places. Are the Purposes and SegmentTypes defined in a document anywhere? That is probably all I really need.

tim.smith | 2016-10-06 14:15:41 UTC | #9

The documentation for conversations is here: https://developer.mypurecloud.com/api/rest/v2/conversations/overview.html

That page doesn't have anything documenting the possible purposes. However, the documentation describes purpose as "A well known string that specifies the purpose of this participant." So since it's "well known", you shouldn't have any trouble finding it... :slight_smile:

I've created API-2003 to create more documentation around the conversation object. I've specifically noted the need to explain a participant's purpose and a segment's type. Are there any other properties/concepts you'd like to specifically call out for additional documentation?

andygunther | 2016-10-06 14:57:21 UTC | #10

Any of the properties that are enums should be documented and defined.

For example, I have a call, with the following Purpose|SegmentType combinations:

From this, I can't define the path of the call. It looks like the call came in, hit a small bit of IVR/Architect Routing, then went to an agent and the agent never answered. Or, maybe they did, but the final two segments show the call with an Alert SegmentType - so, I can't tell.

tim.smith | 2016-10-06 15:12:19 UTC | #11

Thanks, I'll note documenting that for the issue.

From that list, it looks like the call went to the IVR, was ACD routed, tried to be assigned to an agent twice, then the call ended. A normal flow would have:

Here's an example of an agent not answering a call:

{ "participantId": "4a367ccd-7f76-4609-a0bf-a2560b1957bc", "userId": "9ed7d9f6-0c59-4360-ac54-40dd35eb9c2f", "purpose": "agent", "sessions": [ { "mediaType": "voice", "sessionId": "a68b5565-859e-43be-bd04-826245e54921", "ani": "sip:+13172222222@10.145.27.104;user=phone", "direction": "inbound", "dnis": "sip:Hollywoo_1@10.145.27.104", "edgeId": "224678e6-e015-47b0-9d1d-df3cafedfa2b", "segments": [ { "segmentStart": "2016-10-05T16:13:27.670Z", "segmentEnd": "2016-10-05T16:13:35.042Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "disconnectType": "client", "segmentType": "alert", "conference": false } ] } ] }

And here's what it looks like when the agent answers:

{ "participantId": "677c4eb6-dd5e-4da6-94df-dfb74980c054", "userId": "9ed7d9f6-0c59-4360-ac54-40dd35eb9c2f", "purpose": "agent", "sessions": [ { "mediaType": "voice", "sessionId": "0f6a4d66-625f-48d3-8590-a1032ce8700a", "ani": "tel:+13172222222;tgrp=e074b8b7-7f8e-443b-adfd-14a70dcf3e31;trunk-context=hollywoo", "direction": "inbound", "dnis": "sip:Hollywoo_1@10.145.27.104", "edgeId": "224678e6-e015-47b0-9d1d-df3cafedfa2b", "segments": [ { "segmentStart": "2016-10-05T16:13:45.922Z", "segmentEnd": "2016-10-05T16:13:50.342Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "segmentType": "alert", "conference": false }, { "segmentStart": "2016-10-05T16:13:50.342Z", "segmentEnd": "2016-10-05T16:23:42.485Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "disconnectType": "client", "segmentType": "interact", "conference": false }, { "segmentStart": "2016-10-05T16:23:25.153Z", "segmentEnd": "2016-10-05T16:23:25.153Z", "queueId": "636f60d4-04d9-4715-9350-7125b9b553db", "wrapUpCode": "3b9a84d0-5c50-4ce8-918a-f2080c11fad1", "wrapUpNote": "", "disconnectType": "client", "segmentType": "wrapup", "conference": false } ] } ] }

andygunther | 2016-10-06 15:18:02 UTC | #12

OK, in that case, then it appears that the Interact segmentType is not just interacting between two people. When the caller is in the IVR, they are "Interact"ing, and the same when they enter the ACD queue - perhaps hearing a QA message before we alert the agent?

I understand the Agent purposes, but I'm still not clear on what Customer | Interact is as compared to IVR | IVR?

How would we define the beginning of that call, before it got to ACD:

tim.smith | 2016-10-06 15:42:06 UTC | #13

You have to clean all that 1:1 CIC nonsense out of your brain. ;) In PureCloud, all conversations are technically conferences from the very beginning. It's just typically only two parties in the conference at any given time so it looks like a 1:1 call. So the segment type of interact indicates that the participant is actively interacting with the conversation; they are not alerting or in a system state. They are an active participant in the conversation.

You know the customer was actively participating in the call from their segmentStart time to the segmentEnd time. To see what participants they interacted with, compare each participant's start and end times with the customer's to identify those that overlap. This will show you things like "when the customer was interacting with the IVR", "when the customer was waiting in queue", and "when the customer was talking to an agent".

As to why the IVR segment has a type of ivr instead of interact, the best answer I have for you is "because". I believe the IVR microservice interacts directly with the edge, so it's able to provide its own segment type that's different than what the conversation microservice provides. Just know that an IVR participant with the purpose ivr is when the IVR is actively participating in the conversation. I'm not aware of any reason you can't treat "IVR | ivr" as if it were "IVR | interact".

andygunther | 2016-10-06 16:35:28 UTC | #14

Cool, that helps a lot. I hadn't noticed the Customer Segment End time as compared to the other segments. I was looking at Start Times... Thanks!

andygunther | 2016-10-06 20:44:45 UTC | #15

OK, I just want to validate before I make an assumption here...

I have this call:

In this case, the total Customer Duration is 18.86 seconds.

The combination of the Ivr, Acd, and Agent segments (less the Agent | Wrapup) is 26.266 seconds

I'm trying to understand the discrepancy. I believe it is the Acd | Interact segment - but that doesn't give me a dead match. It's about a half second different (0.612).

Is it possible that recording or something like that is injecting a segment to tap the conversation for it's purpose? Or, am I way off track here? What would explain the difference?

andygunther | 2016-10-06 21:04:45 UTC | #16

Actually, it looks like ACD | Interact and Agent | Alert may overlap, with the difference between them plus ACD | Delay being ACD Wait Time.

That brings the discrepancy down to 0.02 seconds. Does that seem right?

andygunther | 2016-10-06 21:21:47 UTC | #17

OK, that's it. I can confirm the overlap for sure between those segments...

tim.smith | 2016-10-06 21:53:52 UTC | #18

Actually, it looks like ACD | Interact and Agent | Alert may overlap

Yes, I would expect this. The queue doesn't exit the conversation until the agent actually answers the call. Remember, there's no requirement for any participants to be 1:1 or for the flow between participants to be linear. The queue is joining the conversation to play hold music and control the call, but drops out once it sees a user has joined (as opposed to the call being transferred from the queue to the user. The queue doesn't "have" the call; it's just another participant in the conversation).

system | 2017-08-28 19:27:44 UTC | #19

This post was migrated from the old Developer Forum.

ref: 468