We have an integration that retrieves the voice transcription in https://api.usw2.pure.cloud/api/v2/conversations/ when recordingstate = active. Lately, we've seen that on some calls, the recordingstate returns as 'paused'.
Client has advised they have secure pause completely disabled, so it's not the user intiating this, and i can see it coming back in the logs:
"calls": [
{
"state": "connected",
"initialState": "offering",
"id": "cebe513b-b215-3fbc-96cc-b2fa4505f7d8",
"direction": "inbound",
"recording": true,
"recordingState": "paused",
"muted": false,
"confined": false,
"held": false,
"securePause": false,
In our implementation, we only look for recordingstate = active and have previously not had an issue until recently. Is there something on the Genesys end that would determine this state to be in paused? Client has confirmed that the full transcript still comes back to them in their call recordings, but it seems to stop us connecting to the live call in progress.
From speaking to the appropriate team, if the customer has hold suppression enabled on their trunk, or if your flow/queue is set up to suppress recordings while in that flow/queue: Call recording in Genesys Cloud overview - Genesys Cloud Resource Center In any of those cases, the recording would be paused without an explicit initiation from the user (either due to the customer being on hold with hold suppression enabled, or the customer being in a flow/queue that has flow/queue suppression enabled). Are you able to confirm if that may be the case in these conversations ?
Hi Zino, Thank you for checking into this for me. I checked in with the client and they've advised:
I took a look at our trunks, queues and policies.
It looks like we don't have any suppression set at the trunk level. At the queue level, all of the queues we have the integration setup on are currently set to not continue recording during "queue wait".
Also, I double checked and made sure none of our policies (hold suppression / recording suppression) were applied to the these queues.
Would there be any other settings that might cause this somewhere? I must note, this issue seemed to only start occurring after there was some maintenance done on the transcription API recently (about 2 weeks ago)