In many cases, when I compare the difference between the recording start/end time with the length of the actual audio file, they are very different. Should this be the case, or is there another source of truth that gives the length of the actual file?
The values are often off by a very small amount due to a difference in when the command to start recording created a timestamp and when the recording actually started. More than a second would more likely be explained by pauses during the recording. If you listen to the recording and look at the interaction's events, that may shed some light. If you're unable to reconcile this, please open a case with Genesys Cloud Care to investigate as we do not have access to your org's data to be able to investigate this.
1 Like
Thanks, Tim. That pointed me to the correct place and answers a lot of questions for me. I am brought now to the /api/v2/conversations/:conversationId/recordings/:recordingId/annotations api call that shows me exactly where my "missing" audio is, and that brings me to my next related questions:
We are using the batch job to pull audio to avoid rate limiting, and one api we call during that process is the /api/v2/conversations/:conversationId/recordingmetadata/:recordingId which I see has an array property "annotations" that is always empty. Is there a way to have this populated so I do not have to hit the annotations api route for each individual call, which would then double the number of api calls for each recording?
Currently, I am looking into aggregating the pause time from the ConversationWithoutAttributes object, but what setting should I ask our client about which types of segments on which they pause recordings?
That property is documented as "Annotations that belong to the recording. Populated when recording filestate is AVAILABLE.". Have you confirmed that the fileState property has the value AVAILABLE? If it's not, I wouldn't expect the property to be populated. If it is, verify that there actually are annotations for that recording using the /annotations endpoint. If one gives you data and the other doesn't, that will need to be investigated by Care.
I'm not sure what you're looking for here. From a technical perspective, I would suggest coding your application to look at all segments that are part of the recording and not artificially constrain your calculation based on a business rule. Unless of course that's what you're intending to do, in which case your client will have to tell you how to account for their business rules.
1 Like
Thanks again for the quick response.
The fileState property for my recording metadata records are all "AVAILABLE", but looking into that led me to the fact that I need to confirm that I need the permission recording:annotation:view, otherwise the annotations will not populate.
Regarding my last question, regarding the conversation object, I probably did not explain well enough. I was looking more for specific metrics such as when participant.purpose=ivr/acd, aggregating the values of the metric names "tivr" and "tacd" in order to find how much time will be omitted from the recording. But I will ask the customer to be sure we have the correct permission to view the annotation in the recording metadata api as that will solve all of our problems.
Ah, that's right. That's mentioned in the description in GET /api/v2/conversations/{conversationId}/recordingmetadata but not GET /api/v2/conversations/{conversationId}/recordingmetadata/{recordingId}. I believe the permission condition does apply to both resources. Failing that permission check is silent, so you can't reliably distinguish the cause of no data without making some assumptions.
I see what you mean. I don't think it's quite that simple. There's too many variables that could affect the recording timing to make any decisive blanket statements about that. How you've configured your recording rules, secure pauses, and how you handle calls with transfers and such could affect how you calculate that. I would suggest looking at the interaction timeline view in the UI and the API data for a specific conversation to work out exactly what math you want to use to get the right number for that conversation, then spot check that math for other conversations you'd be reporting on to make sure you're consistently getting the result you expect.
1 Like
I encountered the same issue that neither /api/v2/conversations/{conversationId}/recordingmetadata nor /api/v2/conversations/{conversationId}/recordingmetadata/{recordingId} is returning the annotation to me, whereas the /api/v2/conversations/{conversationId}/recordings/{recordingId}/annotations does.
I have ensured that I have both permission recording:recording:view and recording:annotation:view so this is not the reason.
I believe it has more to do with the "Recording service API metadata endpoint annotation deprecation" in 2021. Although the API itself is not deprecated, the API no longer returns annotation. See Recording service API metadata endpoint annotation deprecation - Genesys Cloud Resource Center
TLDR: To obtain annotation, use /api/v2/conversations/{conversationId}/recordings/{recordingId}/annotations
1 Like
Yes, I see that the annotations api returns the annotations, while the recording metadata api annotation field has been deprecated, though it seems that it was deprecated, then was brought back, and I suppose was deprecated again.
This presents a new problem for us. In another project, Genesys steered us toward bulk audio download due to a rate limiting issue we were having, which we now utilize.. Now it looks like we will need to use the annotation api, which not only means we will need to hit an additional api for each audio recording, but we will also be subject to a stricter api limit of 120 for annotations api as well as the overall token limit of 300.
Is there another way? I'm afraid rate limit mitigation will severely affect the performance of our application.
Please open a case with Genesys Cloud Care to investigate this. We don't have access to your org's data via the forum to look into it. Those endpoints should all return annotations if you have permissions, as far as I know. The property is documented, so it is expected to work.
The deprecation you linked was not implemented, so no change should have happened. If something did change that wasn't announced, that needs to be reported to Care.
The same advice applies here as well. Please open a case with Care if the annotations are not present in the response as expected.
1 Like
Thank you Tim.
FYI I have opened a Support Ticket (0003492166) as you advised, and yesterday their Engineer replied me that recordingmetadata API is not supposed to return annotation.
I will suggest them updating the API documentation to avoid confusion.
1 Like
Thanks for the update! I have asked that the Care engineer report this as a bug to the dev team so that the property can be removed from the API's contract since it is not in use. There is a formal due dilligence process for removing things from the API contract, so it will take a while for the change to take effect. But at least now you should have a clearer picture of which API endpoints will return the data you're looking for.
1 Like
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.