So my integration made it past the initial round of beta testing and everything seemed to be working great. Then we let a handful of agents test it, and ran into a strange problem: some agents are unable to receive incoming calls. To further complicate things, one agent sometimes can, sometimes can’t.
• We’ve ruled out cross-browser issues because everybody is running the same version of the same browser (Chromium embedded in an NW.js desktop app, latest stable version of NW).
We’ve ruled out permissions issues on our desktop app; it was installed by our IT team and given all the permissions it needs (and the desktop app just adds some global hotkeys, for things like i.e. the Answer button, so it doesn’t require anything network-related). Also, these people experience the same problem running it in the browser.
We’ve ruled out the firewall. We’ve made sure Windows Defender doesn’t block any of the ports documented here, so unless the SDK uses different ports, that’s not it.
And this really doesn’t seem like a code problem.
I’ve checked my logs, and the only errors logged were unrelated (an agent triggered them during a transfer). This lack of logs makes sense, because if a person is not getting calls, there’s nothing to log (and in all my session event handlers I have try/catch blocks that would log errors if they occurred; I have window.onerror writing to logs too).
We looked at the logs generated by Genesys, and unfortunately didn’t know what to make of it. It appears to be all about components of the SDK itself, with essentially meaningless names like “scripter” and “gux” and “Lodash”; similarly, the errors (which were few and far between), also referred to SDK internals. So unless there’s some publicly-available reference documentation for the inner workings of the SDK, those logs don’t seems to help at all (though if you’ve found a way to use them, please let me know).
And just from a common sense perspective, if it were a bug, it would either be broken for everybody or be something we could consistently reproduce (something triggered by user error, or something where if a user does A and then B and then C it’ll throw X etc.). But it’s nothing like that. I can take calls just fine, and so can our beta testers, and so can about half of agents we had testing this.
We tried submitting a ticket to the support team, but the response we got was (in a nutshell) that because it wasn’t regarding the Genesys Cloud client interface, it was not their problem. They pointed me back here, so... here we are.
At this point our only theories are:
Users’ ISPs could be blocking those ports (we’re talking remote agents here, so that introduces a whole other set of factors to consider)
The SDK might use different ports from the Genesys Cloud client, so it could be firewall-related (and I have no way of knowing what ports it uses, as those kinds of low-level details are abstracted away so all I know is what happens inside onPendingSession or onSessionStart etc.).
Could it be API usage limits? I’ve read enough forum posts to know they exist, but I don’t see anything obvious in my logs or Genesys’ logs to point to that.
The truth is, we’re not really sure what the problem could be. So, any ideas on the subject would be greatly appreciated. Thanks in advance.
Can you be more specific about the nature of this issue? Is it that they're getting calls assigned but trying to update the state to connected doesn't work? Or you get an error? Are they not being offered any calls? Do you mean ACD distribution or direct dials internally or externally?
This doesn't seem appropriate to kick to the forum on the surface, but I want to understand what the actual problem is before proceeding. Providing specific API request details and correlation IDs demonstrating the issue will be helpful.
Also, what does the integration do? Is it a web app or something else? I don't see a description of it. Are agents also using the out of the box Genesys UI in tandem with your integration?
I will forward your second question to our IT team, as I don't really know how to answer most of it. There are no errors - as far as my code concerned, no calls are coming in, so there's nothing to log. I'm sure if I could decipher the logs Genesys produces, I might be able to give a more meaningful answer, but I'm hoping our IT guys will be able to provide more info.
To your third question (how we're using the SDK), at this point it's basically just a softphone. It is a web app as far as the SDK is concerned. I expect that over time we will need to integrate it with other tools/APIs, but for now its only real purpose is for agent use (for making/taking calls). They're not using it in tandem with the default Genesys client (if they were, that might help us understand what's going on lol). The desktop component is only important in that it does some things a browser can't, (in this instance it just adds global hotkeys). We do a lot of automating other systems using native code as well (and NW makes running native code from the DOM and vice versa possible), but there isn't anything like that here. And like I said, the issue is affecting these people regardless of whether they're using the desktop app or in a browser. At least for now - and probably always will be as far as Genesys integration is concerned - it's just a softphone/client. It's nothing against the default client, but having full control over the interface will make integrating with campaign-specific software a whole lot easier (not to mention those hotkeys).
Anyway, I will get back to you on those other questions. Thanks for the quick response on this!
EDIT: As far as "specific API request details and correlation IDs demonstrating the issue"... so, on my end there are no API calls. It's the WebRTC SDK. It's like pendingSession never gets called, like they're not being offered calls. Like I said, idk if that's really the case (my code just listens for events like pendingSession and sessionStart - those events are not being triggered. What happens before then I don't know, much less how to get "correlation IDs" from the SDK). I'm e-mailing the other questions now.
Thanks for the details! Your answers are sufficient to direct you back to Care. I'll escalate the case on my end to ensure they proceed with an investigation.
That significantly helps isolate the issue and insinuates a question that Care will be able to answer. Users of your app aren't being considered ready to take a call for some reason. Determining what that reason is isn't something we can assist with on the forum since it requires access to your org's data that we do not have, but Care does. The question to pose to Care is "why isn't user XXX being assigned conversation ID YYY?". That question doesn't require knowledge of anything on the client side; it's purely a server-side investigation that only Care can conduct.
From your end, you'll need to do your due diligence to ensure that your app has taken all the appropriate steps to be ready to take a call. Off the top of my head, those should be:
User's presence is available
User has set their station
If considering ACD assignment:
User's routing status is on queue (IDLE)
The user is in the same queue as the conversation that's pending assignment
The user is skilled appropriately to handle the conversation per its settings and routing config
The user is otherwise not already utilized with other media preventing taking a voice conversation
The case with Care states that the user is able to receive calls as soon as they open the Genesys client, so that points to one of the temporal states like presence, routing status, or station readiness, as opposed to a persistent configuration issue with the queue or skills.
@LighthouseMike Care has asked me to ask you to ask them to reopen the ticket. If you could post an update in the case asking them to proceed with working your issue, that should get the case moving.
