Hi guys,
So it's been reported that users are getting stuck in "not responding" a lot - sometimes while they're on a call. After investigating the issue further, I found code on my end that was basically saying, "if the user is already on a call, do nothing" (which some jokes in there describing this "bizarre bug on Genesys' end"). I talked it over at length with one of the guys who is more familiar with the end-user's workflow, and we think that code is the culprit. In other words:
A call comes in. Genesys sends my app a pendingSession event. My app shows a pop-up with an Answer button.
The user answers the call. The user clicks Answer, and the conversation goes as normal.
Something else happens. Something else tells Genesys to send this user an incoming call, apparently somehow unaware of the fact that s/he is already on a call.
My app does what it was programmed to do. It sees another pendingSession and ignores it.
Genesys "thinks" the user declined the call. It misreads my ignoring the second incoming call (while on a call) as "the user goofed" and puts the user in "not responding".
as a result, from the SDK's standpoint, the user s failing to answer an incoming call and so Genesys put them in "not responding".
Now I've only ever seen this pendingSession-while-on-a-call thing a few times, during the initial development process, so I know it's a thing that can happen... but I have no idea what to do about it. All I really know is what my code does currently is somehow wrong.
So... so many questions here, I'm sorry, I don't even know where to start:
What, besides an incoming call (if anything), can trigger a pendingSession event?
Could something else, besides a pendingSession the user didn't accept, could cause Genesys to kick a user into the "not responding" status? The guy I was having this similar conversation with found this alternate documentation site that seems to suggest the answer is "no, only users failing to answer calls"... sooo....
If the user is already in a call, and my software receives another pendingSession event... how should it handle that? Most users have only one mouth.
All joking aside... I don't think I should call acceptPendingSession because that might start a second call at the same time.... sort of like a transfer but not really (one agent, two different customers). Is there some kind of preventMoreIncomingCalls type of thing I have to call? Some other parameter I have to pass to the first acceptPendingSession to tell it not to send this users more calls until his/her status is "idle"?
Also... is there a way I can cause whatever circumstances tell Genesys to send users a second pendingSession event? The trouble with debugging things like this is often that there never seems to be a reliable way of reproducing the issue. I mean... do I flood my test DID with calls, or what? Like, how can I get my software to receive a second call while on a call, so I can try different things and see what solves it? Or maybe there's another notification I have to listen for someplace? lol this one has me so confused.
So we had a bug in a previous version where it was possible to get two pendingSession events for a single call, but that sounds like it's different than what you are describing. There are only two ways to get a pendingSession event. First, you are receiving a pendingSession, obviously. Second, the sdk creates a fake pendingSession event if the station is configured to maintain a persistent connection and it gets a conversation update indicating it has an alerting call and it already has an active/idle softphone session. This is so the implementation differences between persistent connection and single use sessions is invisible to the consumer. It is possible to get pendingSession events for other session types (such as screen recording) while on a call, but ignoring that pendingSession would not result in a "not responding" state and by default those sessionTypes are not handled unless explicitly configured to do so.
There is a weird race condition the sdk should be handling in the case of persistent connection which can also result in a second pendingSession event, but it would have the same conversationId and answer either of them would answer the call so I don't think that would be your issue. In your case, I think the best thing to do would be to get the conversation ids of both the pendingSessions and open a CARE ticket to make sure you aren't actually receiving two separate calls.
We don't have any special handling for cases where you receive multiple calls simultaneously, that's why I'm thinking you might have a different problem than something in the sdk such as a call routing configuration issue. I understand it might be difficult to get the conversationIds when this happens. If you can get timestamp of roughly when this happened (the more precise the better) and to which agent, CARE should be able to find the conversationIds for you and look into this further
fake pendingSession events: This is an easy one I will start coding a check for. If the conversation IDs are the same, then we know that is happening; it sounds like that's not the cause of all the "users getting thrown into Not Responding a lot more" problem, but it's still a check I'd like to run just cuz. Unpredictable randomness like this tends to turn me into a loggaholic.
Weird race condition / something else: I agree, it sounds like "someting else" (and weird is absolutely the best word possible to describe it ). So hopefully by adding those extra checks / that extra logging in #2 above, that will lead to a lead on how to debug this. Thank you.
In response to #1, v7 is pretty old at this point. v8 is the new hotness which has a lot of bug fixes in it. v8.2.0 will be released on the cdn in the next 24h or so which will be the best candidate. For a list of all the fixes, changes, and breaking changes, please have a look at https://github.com/MyPureCloud/genesys-cloud-webrtc-sdk/blob/develop/changelog.md
Wow... yeah, looks like you guys are moving pretty fast on these updates - and version 8.1.6 actually mentions something similar to what we've been talking about with pendingSession events... so this could very well be the issue - or at least part of it. I've already added the extra logging so we get the conversation IDs, and I'm going to try with the v8 SDK here shortly. Once I know I can take calls and all that still works with the new SDK update, I'll let our beta team have at it and take it from there. Thank you very much for this info.
PS: I like that, "the new hotness" - I've never called any of my projects that, but I know the feeling! Hard not to be proud when you roll out something awesome!
So I've been doing some heavy rework, setting it up so that:
There is only one JS file that ever call into Genesys stuff directly. This gives me a single point of failure for debugging (versus the current production setup, where there are all kinds of API calls going on in different places).
All events and notifications received from Genesys, and all user actions (button clicks etc.) get logged, giving me a complete "play-by-play" of everything that happens, as it happens. I even created a little custom "terminal" tool (using xterm.js) for searching and filtering logs by file, function, stack trace etc.
These changes are not ready to go live yet, but in both my dev build and the current production release, the issue with people going into "not responding" (for no apparent reason) continues. At one point (last week I think) I had coded a little pop-up that listened for a not-responding notification and then showed a modal dialog where users could go back on... and then immediately had to get rid of it because people were getting the pop-up while they were on a call. I also heard this morning that sometimes, when a user is not on a call, she/he will hear "Call disconnected" (a thing my program says when a sessionEnded event fires).
Frankly, this not responding problem has been driving me absolutely bananas, as there appears to be no logical explanation for it apart from getting unexpected sessionStart/sessionEnd events while on a call. I mean all the docs really say on the subject is:
pendingSession is "Emitted when a call session is being initiated for an outbound or inbound call."
sessionStarted is "Emitted when negotiation has started; before the session has connected" (wait... should I be listening for connect instead?)
sessionEnded is "Emitted when a session has ended".
But clearly, there is much more to it than that. I saw the post above about how sometimes pendingSession will send dupes... am I listening for the wrong events or something? Maybe those event names don't mean what I think they mean.
EDIT: Re: sessionStarted... I'm not sure I understand "negotiation" either... the campaign we're working on doesn't do any kind of legal or business negotiation... probably me misunderstanding your slanguage lol. Might be confirmation that I'm listening for the wrong events.
