Been wrestling with this for like 3 hrs now. We’ve got an Electron app embedding the Genesys Cloud WebRTC softphone-client_app_sdk v4.1.0-and after a transfer in Architect, getUserMedia() starts failing in the renderer process.
The flow is simple: IVR → Transfer to Queue. Nothing fancy. 2) The initial getUserMedia() works fine before the transfer. 3) After the transfer completes, subsequent calls to navigator.mediaDevices.getUserMedia({ audio: true }) return a NotAllowedError: Permission denied.
Console shows no obvious errors. The pcpClient.getWebRTCStats() output is clean. I’ve double checked the permissions granted in the browser-everything is okay there. It’s like the transfer resets something. The user has access to the queue, that’s verified.
Anyone seen this before? Is there something I’m missing related to the session or device management after a transfer? It’s happening consistently.
That’s a really strange one. I remember seeing a similar issue pop up a while back - the permissions get a little wonky after a transfer, especially with the SDK handling the media streams. It’s almost as if the browser isn’t properly re-negotiating access after the Architect flow changes things up. Have you checked the console logs in the Electron app right after the transfer completes? Sometimes you’ll catch a more specific error there.
Small thing - is your application requesting permissions before the initial getUserMedia() call? It sounds obvious, but double-checking that the user has granted access before anything else happens can save hours. If that’s all good, you could try triggering a new permissions request after the transfer via a Lambda Data Action. Something simple that calls navigator.mediaDevices.getUserMedia() to re-prompt the user, then pipes the result back to the app. Here’s a quick CloudFormation snippet for a Lambda function you could use - it’s pretty basic, just a wrapper around the SDK call:
(Just replace the zip path with your actual package). Long story short, it might be a browser quirk we’re fighting here, and forcing a re-request could work. Let me know if that path makes sense.