jab | 2023-04-05 14:08:27 UTC | #1
Desired behavior: call conversation details endpoint and only receive conversations that have an existing recording.
Flow our application is currently using:
- Execute a post request to the conversation details endpoint, include segmentFilters to only retrieve conversations where recording exists
POST https://api.usw2.pure.cloud/api/v2/analytics/conversations/details/query { "interval": "2023-04-03T10:49:00.108Z/2023-04-03T10:50:53.656Z", "conversationFilters": [ { "type": "and", "predicates": [ { "type": "dimension", "dimension": "conversationEnd", "operator": "exists" } ] } ], "segmentFilters": [ { "type": "and", "predicates": [ { "type": "dimension", "dimension": "mediaType", "operator": "matches", "value": "voice" }, { "type": "dimension", "dimension": "recording", "operator": "exists" } ] } ], "order": "asc" }
- Iterate through conversation ids returned from this query and get recording metadata for each
GET https://api.usw2.pure.cloud/api/v2/conversations/81100763-e690-4eb1-89f4-8fbb03b2c293/recordingmetadata
We are receiving conversation Ids from step 1 that return an empty array on step 2. How can that be the case given the filters we are utilizing in step 1?
crespino | 2023-04-07 16:18:08 UTC | #2
So there a few things that some testing of live calls would show you.
First, if the trunk is setup to record calls and a recording policy is configured properly, then when a call is actively being handled by an agent the Conversation JSON will have recording=true and recordingState=active. When the agent hangs that call up, you'll see those properties change to recording=false and recordingState=none.
So in your query, you are checking if the recording property exists, which means is it in the JSON and does it have a value. Well, it always exists in the JSON and will have a value of true or false, so 'exists' will always evaluate to true.
Additionally, from the simple testing above, the recording and recordingState are used by Genesys to indicate the current state of recording at a snapshot in time and should not be used to indicate the existence of a recording file for that particular call. For instance, once the agent hangs up the active call, those values are recording=false and recordingState=none meaning that the call is not actively being recorded (because the call has been hung up), but there is a recording of the call.
So you will need to remove that segment filter from your query. You'll need to use Analytics to query for the calls that you want in the time range and then you'll have to call the /api/v2/conversations/{id}/recordingmetadata for each conversation returned to see if a recording exists for that call.
Alternatively Genesys provides an AWS S3 Recording Integration that customers can install to automatically push recordings to an S3 bucket. You'll get both a recording file and a metadata file. Using this mechanism there is no need to call any Genesys APIs because if there is a recording then Genesys will export it. Therefore you will always get all recordings for all calls that have a recording.
I hope that helps.
jab | 2023-04-10 17:32:40 UTC | #3
I see. So it sounds like the most amount of filtering we would be able to do here is to filter for recording=false and recordingState=none, since that at least should avoid pulling active conversations that have not completed?
system | 2023-05-11 17:33:25 UTC | #4
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 19321