getUserMedia() failing after Architect transfer - weird permissions thing?

General Discussion
1

Hey all,

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.

  1. 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.

2

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:

Resources:
 LambdaFunction:
 Type: AWS::Lambda::Function
 Properties:
 FunctionName: reinitMediaPermissions
 Runtime: nodejs16.x
 Handler: index.handler
 Code:
 ZipFile: path/to/your/lambda/package.zip

(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.

3

That fix worked - switching the scope in the OAuth settings got it sorted, the 403 is gone. It was somehow picking up the wrong client ID after the transfer - took like 2 hrs to track down. Didn’t realize the SDK was so sensitive to that.

1 Like
4
  • Check the softphone client’s authentication; it’s likely re-authenticating as a different user after the transfer; hence the permissions issue.
  • Review the OAuth scopes; ensure they include all necessary media device permissions; for what it’s worth, the microphone and camera scopes are essential.
  • Inspect the softphone.js initialization; verify the clientId and userId are correctly propagated post-transfer; a mismatch there can trigger unexpected behavior.
  • Check the user’s verifier status to ensure the session is valid; you can verify this by initiating a WebAuthn registration check via POST /api/v2/users/me/verifiers/webauthn/register/options to see if the platform accepts the current user context.
  • The SDK’s event listeners might need re-registration after a transfer; re-establish them to ensure proper state synchronization; it’s a common oversight.
  • Small thing: confirm the Architect flow isn’t inadvertently clearing the user session or altering the OAuth token; that’s a subtle but possible source of errors.
1 Like