We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

We are also using an embedded framework connector with ServiceNow for many agents and we're battling this same issue among other possible API connection/delay issues like connector buttons are grayed-out.  When we find out more on our cause(s), I'll share back to this thread.  It is very difficult to determine root cause and we had to also sort out some ISP-specific issues for some agents.  You can try a different browser and also try enabling the persistent WebRTC connection for some agents to see if that helps but we so far did not see any improvement. We are currently monitoring client browser logs and having them report the occurrences to our support team to review and determine the cause(s).

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

yeah.  I guess we are in the same boat.  If we could recreate the problem 100% of the time, it would be great.  The big issue we have is an agent has the issue and it can bounce the call to the agent sitting right next to them and they can answer the call.  If I get any update, I will post as well.  Thanks for the feedback.

We are also using an embedded framework connector with ServiceNow for many agents and we're battling this same issue among other possible API connection/delay issues like connector buttons are grayed-out.  When we find out more on our cause(s), I'll share back to this thread.  It is very difficult to determine root cause and we had to also sort out some ISP-specific issues for some agents.  You can try a different browser and also try enabling the persistent WebRTC connection for some agents to see if that helps but we so far did not see any improvement. We are currently monitoring client browser logs and having them report the occurrences to our support team to review and determine the cause(s).

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Brian, are you finding that the issue is worse in the afternoon for you? There's a marked uptick in this issue after 12pm central for us.

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Scott - I wouldn't say there's a definitive time of day for us, however we do tend to see more support tickets come in mid-morning and mid-afternoon which is when our (and likely other's) peak call times are. There are just so many factors that can come into play with the embedded client & webrtc phone performance/reliability. As perfectly reliable as we want it and the device/platform/network/etc it sits on to be, it's just not, regardless of what anybody says/wants to believe.

What would help is if a very specific error would be thrown when a call cannot be answered, regardless of the logging level. For fun, maybe they could say something like:

• Your network performance was subpar at the exact moment the call was sent to you. You may want to do something about that before your next call.
• I'm sorry, Dave...the Genesys Edge did not have the capacity to send the call to your webrtc phone right now.
• Negative ghost rider...the Google Chrome cache is full. You're gonna have to circle around a few more times before I can send you a call.
• I'm not sure if you noticed, but both your device's CPU & Memory are so maxed out that had I sent that call through your device would've exploded like a Samsung Galaxy Note 7.
• **Yawn** I'm so sorry...I was just waking up from sleep mode and missed your call. I promise it won't happen again...until your next break, lunch, or moment when your webrtc persistent connection fails.
• My bad you missed that call. You see, what had happen was, I just got this new DNS Lease and was busy showing it off.
• Quick question; does this wired connection make me look fat? Oh you'd better not try to take that call instead of answering me. Fine--let's see how you feel when I change into my Wi-Fi connection right when you try to answer that call.

Brian, are you finding that the issue is worse in the afternoon for you? There's a marked uptick in this issue after 12pm central for us.

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Scott - I wouldn't say there's a definitive time of day for us, however we do tend to see more support tickets come in mid-morning and mid-afternoon which is when our (and likely other's) peak call times are. There are just so many factors that can come into play with the embedded client & webrtc phone performance/reliability. As perfectly reliable as we want it and the device/platform/network/etc it sits on to be, it's just not, regardless of what anybody says/wants to believe.

What would help is if a very specific error would be thrown when a call cannot be answered, regardless of the logging level. For fun, maybe they could say something like:

• Your network performance was subpar at the exact moment the call was sent to you. You may want to do something about that before your next call.
• I'm sorry, Dave...the Genesys Edge did not have the capacity to send the call to your webrtc phone right now.
• Negative ghost rider...the Google Chrome cache is full. You're gonna have to circle around a few more times before I can send you a call.
• I'm not sure if you noticed, but both your device's CPU & Memory are so maxed out that had I sent that call through your device would've exploded like a Samsung Galaxy Note 7.
• **Yawn** I'm so sorry...I was just waking up from sleep mode and missed your call. I promise it won't happen again...until your next break, lunch, or moment when your webrtc persistent connection fails.
• My bad you missed that call. You see, what had happen was, I just got this new DNS Lease and was busy showing it off.
• Quick question; does this wired connection make me look fat? Oh you'd better not try to take that call instead of answering me. Fine--let's see how you feel when I change into my Wi-Fi connection right when you try to answer that call.

Brian, are you finding that the issue is worse in the afternoon for you? There's a marked uptick in this issue after 12pm central for us.

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Brian, are you finding that the issue is worse in the afternoon for you? There's a marked uptick in this issue after 12pm central for us.

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Hi,

If I may answer your question, we also feel that this issue is more present between like 11am to 3pm but it's our peak time so for us this normal to get more ticket between that time.  It also happen randomely during the day.  

If I can summarize a little bit what we tried : 

• Have agent using Agent Desktop Application and the Web Application, same issue; either agent can't pickup the call which leads to Agent No Answer or they get the call but all of the agent page (agent script, info, etc.) got a spinning blue circle that prevent the agent to see who's calling.
• We tried Chrome and Edge, same issue.
• We use Citrix so we tested some users outside of citrix, same issue.
• We asked people who works home to get to the office and see if it gets better, same issue.
• We disabled all Security software that might impact the connectivity, same issue.
• All of our agent has Physical phone so WebRTC is not in scope for us to be the culprite. And honestly, voice is crystal clear.
• We also target the Single Sign On in case there was something happening behind de scene, and ask our users to use the Genesys Native login, same issue.
• We played with Browsers performance configuration, no improvement

I probably forgot other thing we look at like frontend, Firewall, etc... but for me, it tends to point into Genesys direction. They're now grabbing network stats from us where we are providing Conversation ID for analysis... hope they'll find something that can help us all!

Brian, are you finding that the issue is worse in the afternoon for you? There's a marked uptick in this issue after 12pm central for us.

What a pain indeed, Linda. Firefox isn't a viable option for our users, but we'll keep that in mind in case we have an opportunity to test it. That said, I'm not sure why your webrtc pop-up window disappears (ours stays open and just goes to the background while using the other browser). I can only presume your embedded client settings within ServiceNow align with the article, so hopefully Genesys can explain why yours disappears instead of staying open.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 08-09-2023 10:47
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

We use ServiceNow embedded client and a few months ago, agents who were using Firefox started having an issue where they were unable to answer calls via the Widget.  I believe they got some error message in the widget about WebRTC and the webRTC pop-up window would disappear.  After Genesys spent time pointing fingers at the softphone integrator, the solution they found was to add our ServiceNow and Genesys url to the Enhanced Tracking Protection exception list in Firefox.  And now I have started having the same issue in Chrome, but there is no equivalent "Enhanced Tracking Protection" set up in Chrome, except in Incognito Mode, which we aren't using.  I tried adding those same urls to an exception list for 3rd-party cookies but it isn't helping.  Agents haven't started complaining yet but my colleague and I can replicate it on our laptops but not within AWS.  It seems only a matter of time - most of our agents use Chrome.

Since Genesys ultimately found the work around to the issue in Firefox, I am not surprised that they urged Scott to use Firefox.  And I did heed your suggestion to try and collect logs from the WebRTC popup but that pop-up disappears (that is the cause of the problem, actually) and takes the logs with it.

Sigh!  Off to open a ticket. 

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-05-2023 08:09
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

Coincidentally, for the first few days of this week, we saw the same issue intemittently (not every call) crop up for several (not all) of our Salesforce embedded client users (all using webrtc & Genesys Cloud Edges). We had not received reports of this issue prior to this week. Somehow it has now stopped without any intervention on our part or Genesys Support (to our knowledge). Perhaps the weekly Genesys Cloud update had something to do with fixing it (e.g. reset the Edges so users got a fresh connection or something)...dunno.

We were also told to provide network/console logs, but when doing so had to make sure we ran them on the webrtc pop-up window and not the Salesforce window itself. The reason why I mention that is because doing the latter showed no issues to Support, so we had to spend another day running them on the webrtc window. Of course by the time we started the new captures, the issue stopped occurring.

While the issue was occurring, we tried all the things (clearing all cache for all time, logging the user out of their webrtc phone & Genesys Cloud account, logging out of Salesforce, closing all Google Chrome browsers, and logging in fresh to everything), but the issue would still occur. Network/ISP speed was more than sufficient and geographic location had no bearing (we have users spread across the U.S. with various ISPs.) The issue also did not impact our non-emdedded client users (i.e. the native web client or desktop app users.)

The only solution [we think we found] was to switch impacted users to Microsoft Edge, which isn't a viable long-term solution at this time given we're a Google Chrome shop and the Salesforce admins prefer we use Chrome. Plus it would be nice not to run from the issue and find an actual solution. Maybe it's just me, but the Genesys Cloud Edges and/or Google Chrome do seem like primary suspects in this situation 🤔 

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Out of curiosity, of the folks that are in here having the issue, which region are you in? We're in US-West region of Pure Cloud.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Out of curiosity, of the folks that are in here having the issue, which region are you in? We're in US-West region of Pure Cloud.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Out of curiosity, of the folks that are in here having the issue, which region are you in? We're in US-West region of Pure Cloud.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Wow.  I have had a ticket open with Genseys for my issue with not being able to answer calls using the softphone widget in ServiceNow while using Chrome (the WebRTC popup disappears) since August 9th.  This work around has not been offered to me but I just tried it and my WebRTC popup didn't disappear and I could actually answer calls.  So far the problem is not widespread and I am not sure how changing this setting on a "enterprise level" at my organization would work, but at least this is something!

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Wow.  I have had a ticket open with Genseys for my issue with not being able to answer calls using the softphone widget in ServiceNow while using Chrome (the WebRTC popup disappears) since August 9th.  This work around has not been offered to me but I just tried it and my WebRTC popup didn't disappear and I could actually answer calls.  So far the problem is not widespread and I am not sure how changing this setting on a "enterprise level" at my organization would work, but at least this is something!

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Was this an intermittent problem for you, or could you recreate it 100% of the time.  That was our issue, it is very intermittent and seems to happen a lot with some people, but not enough to say they were having a chronic problem.  I had the agent that has the most do this and I will need to see how it works out.

Wow.  I have had a ticket open with Genseys for my issue with not being able to answer calls using the softphone widget in ServiceNow while using Chrome (the WebRTC popup disappears) since August 9th.  This work around has not been offered to me but I just tried it and my WebRTC popup didn't disappear and I could actually answer calls.  So far the problem is not widespread and I am not sure how changing this setting on a "enterprise level" at my organization would work, but at least this is something!

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

John, this issue with the WebRTC popup disappearing, preventing an agent using the Softphone Widget in ServiceNow from being able to answer or initiate calls from the widget while using Chrome, had thus far only been observed by me, personally, while testing something else!  No agents have reported this specific issue and my colleague could not recreate the issue, even with the same version of Chrome.

Agents who use the softphone widget will report other issues that sound similar to what I see in this thread, such as the long delay between when they answer the call and actually connect to it.  But in at least some cases, that may have been due to the agents logging into ServiceNow (and logging into Genesys via the widget) and also logging into Genesys directly on a separate tab. 

There seem to be so many issues with similar symptoms.

I hope the work around Brian shared works for your agent!

Was this an intermittent problem for you, or could you recreate it 100% of the time.  That was our issue, it is very intermittent and seems to happen a lot with some people, but not enough to say they were having a chronic problem.  I had the agent that has the most do this and I will need to see how it works out.

Wow.  I have had a ticket open with Genseys for my issue with not being able to answer calls using the softphone widget in ServiceNow while using Chrome (the WebRTC popup disappears) since August 9th.  This work around has not been offered to me but I just tried it and my WebRTC popup didn't disappear and I could actually answer calls.  So far the problem is not widespread and I am not sure how changing this setting on a "enterprise level" at my organization would work, but at least this is something!

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

As a test, we are installing some SIP phones for some agents to use, rather than the WebRTC phone.  We have tested on the ServiceNow connector and the agent still gets their screen-pop and they can still answer the softphone.  We are hoping they don't have the issue with the WebRTC widget that pops up that you can minimize or close.  Will keep you updated.

On the intermittent part, we are in the same boat.  I keep a running total, but we can see some agents have the issue and some agents never have the issue.  the only thing I am happy about is, we aren't the only ones having the issue, and yes, this has been happening with our ServiceNow agents since they went live.  

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

@John Anaya - Amazing what happens when we take a moment out of our busy days to share actual struggles. You quickly learn how "not alone" we really are, and how common, equally as frustrating, elusive, and virtually impossible to troubleshoot/solve this issue is. It's probably why more people don't talk about it or accept it as the norm, power through, and move on. To piggyback off @Derek Cowan's & @Sylvain Richard's earlier points (& justifiably exhaustive posts), it is rather draining/debilitating.

Thanks for keeping us posted on how the SIP devices work.

As a test, we are installing some SIP phones for some agents to use, rather than the WebRTC phone.  We have tested on the ServiceNow connector and the agent still gets their screen-pop and they can still answer the softphone.  We are hoping they don't have the issue with the WebRTC widget that pops up that you can minimize or close.  Will keep you updated.

On the intermittent part, we are in the same boat.  I keep a running total, but we can see some agents have the issue and some agents never have the issue.  the only thing I am happy about is, we aren't the only ones having the issue, and yes, this has been happening with our ServiceNow agents since they went live.  

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

@Derek Cowan - You pose the million dollar question (How are others tracking occurrences of this?)

That would presume there is some very specific flag/error code/attribute/etc that automatically gets written to an API searchable place when the agent tried to pick up the call, but couldn't. If that were the case, I would think we or Genesys could easily pull a decent list of examples to investigate from a Genesys Cloud Edge perspective.

Given that doesn't seem to be the case (that is until I'm publicly corrected by a community member who does know how to uniquely distinguish those via our performance views without human intervention), the only [less than ideal] recommendation I can make to you is to have your agents manually "flag the call" whenever it happens. That way you can pull a list of flagged calls from the Performance > Workspace > Interactions view or an API call.

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

This is exactly what we're doing.  We shared an excel file with agent and each time they face the situation, they put an entry in the file including date/time/activity/Program-system laging/etc... and Conversation ID.  So at the end of each day, we send those to Genesys for analysis purposes.  Genesys currently monitor 10 agents with their network monitoring tool NetThink.  

We are currently awaiting news from them on their analysis and I'll share with you when I'll get them!

@Derek Cowan - You pose the million dollar question (How are others tracking occurrences of this?)

That would presume there is some very specific flag/error code/attribute/etc that automatically gets written to an API searchable place when the agent tried to pick up the call, but couldn't. If that were the case, I would think we or Genesys could easily pull a decent list of examples to investigate from a Genesys Cloud Edge perspective.

Given that doesn't seem to be the case (that is until I'm publicly corrected by a community member who does know how to uniquely distinguish those via our performance views without human intervention), the only [less than ideal] recommendation I can make to you is to have your agents manually "flag the call" whenever it happens. That way you can pull a list of flagged calls from the Performance > Workspace > Interactions view or an API call.

We've been battling these symptoms for more than a year.  It is the 1 KTBR reported issue we can guarantee to see every month; sometimes it will occur just once in 3 weeks, sometimes it's multiple reports within a morning, and it is by far our most frustrating issue.

We see reports mostly with agents who use the softphone connector for ServiceNow however we have had reports with the Salesforce CTI connector as well.  Most of our agents use a CTI connector to answer calls. We recommend Chrome from the start and when the issue is reported by an agent, we switch them to Edge (and vise-versa) but most run Chrome.  We tend to see the issue does not occur every day but when it occurs, it can be for a 1 agent or a handful of agents but never all nor the majority.  We see this across multiple orgs in USW2 & EUC1.  Logs never seem to help Genesys Support identify a specific cause and for any report of this kind of issue they require logs which is painful and often not possible for an intermittent issue that cannot be recreated on demand (our situation).  We suspected browser features/settings (like Chrome Power/Memory Saver) however they evolve quickly/monthly and tracking down this very intermittent issue has been our biggest support challenge with Genesys Cloud!  We also believed it was more common if an agent had both Genesys WebUI and CTI running in parallel (not advised/supported) but it can occur when they just use CTI.  We did have some initial success trying the Desktop client it seemed however that negates why we purchased CTI connectors and eventually we have rarely seen issues with the desktop client not answering when agents make the attempt.  We have not focused on trying webui solely but suspect it is also vulnerable to the same issues.  We've also tried to correlate reports of the issues to potential API failures but so far have not had luck in finding a direct connection.

How are others tracking occurrences of this? I figured our most common symptom from a reporting side would be to the Interactions view in Performance Workspace and filter by "Not Responding" which should capture our occurrences however it also captures those in which an agent may not have experienced a tool issue and instead may have just missed responding to the incoming interaction alert.  Anyone have other suggestions?

Glad that helped you and some others, @Prem Venkatesh. Jury is still out if it resolves the overall "inability to answer calls/not responding in embedded client" issue though ;o)

Thank you @Brian Jones for the update. One of our customers reported web RTC window was not able to load properly in SF and the above solution to disable the Storage Partitioning fixed the issue.  

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Brian, You noted that Genesys support told you they're working with Google regarding an issue impacting the embedded client and I did find this link: 

Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs (google.com) in which you can see some of the discussion, assuming "Junji Genesys" is a Genesys employee.

In talking with my team, we noticed this week that our "standard" reports of agents clicking accept/pickup but getting set to not responding, changed patterns a bit and we started to receive reports from a handful of agents using an AppFoundry ServiceNow CTI connector, where the small Genesys WebRTC window that opens automatically when you login to CTI, suddenly started to close itself within 1-minute of logging into the CTI connector.  We have not yet seen this impact any of our Salesforce CTI Chrome agents however it seems the issue could impact any cross-site embedded CRM CTI client app. This was only seen by 8 users over the past 7-days however the pattern was they were all on Chrome and started experiencing this odd closure behavior with the small webrtc browser window.  We had never had reports of this behavior over the past year.

We had told them to switch to Edge which worked and now we have attempted the fix noted in your post above which was to update their flag in Chrome (disable 3rd party storage partitioning) and it has resolved the CTI auto-closing webrtc window issue.  Now we're waiting to see if the issue returns for anyone but so far that has fixed the issue for them.   We unfortunately can't recreate the issue with any test clients in our own team but it appears the fix is a good workaround for that specific issue if agents experience it.

We are only seeing this issue with a very small percentage of our CTI agents who use Chrome and we assume that may be due to the way Google rolls out changes in a bit of a ring deployment and also some agents may not have reloaded their browsers since receiving a push from Google but we're not certain.  I do believe that even though 2 clients have the same version of Chrome, one of those clients may actually have different features available in Chrome than the other client (I have experienced this when the Chrome Performance Memory Saver feature began to roll-out). Our suspicion is this issue may continue to roll out soon to other Chrome users in our environment and if we do see an uptick, we may deploy that flag setting in bulk to all clients to pro-actively prevent it from affecting the remaining agents in the future.

Have you seen that flag resolve any of your agents' similar issue?

UPDATE: Support reviewed our logs and provided the following response (although I'm not sure if it was a result of something they found in the logs, which I have asked):

"There is an ongoing investigation by our development team regarding a known issue with a new experimental feature released by Chrome that is affecting any CRM client: Storage Partitioning - Chrome Developers

We ask that all affected customers explicitly disable this setting to prevent the behavior while we investigate the long term solution on our side.

This can be disabled by navigating directly to chrome://flags/#third-party-storage-partitioning in the browser and explicitly setting this configuration to Disabled. There are also a couple of ways to manage this at an enterprise level so that all users do not need to set this flag individually:

https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins

https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting 

It appears that this setting is also present in other Chromium based browsers such as Edge and Brave, the flag location is identical other than the browser name specification so can be found at these locations: 

edge://flags/#third-party-storage-partitioning 

brave://flags/#third-party-storage-partitioning 

As some have noted these browsers are not yet experiencing this issue as it appears they've not yet updated the default setting for it to be enabled, however the suggestion for the time being would still be to disable the setting so that a version update in the near future does not change that and begin causing the same issue with our client.

FYI: The issue (Salesforce embedded client users go into Not Responding when trying to answer an interaction despite being auto-answer with persistent connections) has resurfaced today, so we're reopening our support case from last week and attempting to collect logs again--specifically from the webrtc pop-up window this time.

------------------------------
Brian Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

@ALL - Genesys is still digging into our logs and has made mention they will likely need more logs to review or to replicate the issue live. I pointed them to this as well as a related thread in hopes they can communicate internally [better] about the plethora of logs they likely already have on this issue.

REQUEST: If you are currently experiencing this Not Responding/Inability to Answer an Interaction in the Embedded client issue and have a Case open with Genesys Support, please add your Case number to this thread so we can combine forces to help Support see just how many issues and examples there already are out there. Individually we'll spin our wheels, but together perhaps we can get some traction.

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

Hi Everyone,

Just an update on my specific embedded-client issue (in Service Now using Chrome), where agents were unable to answer or initiate calls using the softphone widget due to the WebRTC popup window closing:

I had the work around in place (shared by Brian way back in entry 20) and I noticed among the weekly updates from Genesys on 8/30 this "Genesys Cloud for Chrome extension update." I asked the Genesys engineer with my ticket if that update was a fix for my disappearing WebRTC popup.  He said it was but they had to roll it back.  Oops?  He later let me know it it had been pushed out again and asked me to test it (without the work around in place).  I did this and, so far so good.

So for anyone experiencing that specific issue with their embedded client in Chrome, maybe this will help you too.

Linda

@ALL - Genesys is still digging into our logs and has made mention they will likely need more logs to review or to replicate the issue live. I pointed them to this as well as a related thread in hopes they can communicate internally [better] about the plethora of logs they likely already have on this issue.

REQUEST: If you are currently experiencing this Not Responding/Inability to Answer an Interaction in the Embedded client issue and have a Case open with Genesys Support, please add your Case number to this thread so we can combine forces to help Support see just how many issues and examples there already are out there. Individually we'll spin our wheels, but together perhaps we can get some traction.

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

First @Linda Greenshields, I'm glad you've found some relief from the webrtc pop-up closing whether it's via the workaround or a recent release.

I do find it interesting that release fixed your issue though given:

1. Their description in the 8/30 release notes doesn't mention anything about fixing the webrtc issue.
2. We use the Genesys Cloud for Salesforce embedded client, so there is no "chrome extension" for us to update per se (i.e. we have never had our users install the "Genesys Cloud for Chrome Extension" given the embedded client is built into Salesforce.)

Ironically though, my support engineer just shared similar information in my current case regarding the webrtc pop-up window issue, but referenced the 9/6 release--the release notes for which also do not mention addressing the webrtc pop-up issue. C'mon Genesys...we need all the deets:

"The development team is still investigating the [Not Responding/Inability to answer calls] issue in the case. I did want to mention however that the development team has released a deployment for the CRM to address the Chrome feature on September 6th."

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 09-11-2023 18:06
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

Hi Everyone,

Just an update on my specific embedded-client issue (in Service Now using Chrome), where agents were unable to answer or initiate calls using the softphone widget due to the WebRTC popup window closing:

I had the work around in place (shared by Brian way back in entry 20) and I noticed among the weekly updates from Genesys on 8/30 this "Genesys Cloud for Chrome extension update." I asked the Genesys engineer with my ticket if that update was a fix for my disappearing WebRTC popup.  He said it was but they had to roll it back.  Oops?  He later let me know it it had been pushed out again and asked me to test it (without the work around in place).  I did this and, so far so good.

So for anyone experiencing that specific issue with their embedded client in Chrome, maybe this will help you too.

Linda

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-31-2023 16:10
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

@ALL - Genesys is still digging into our logs and has made mention they will likely need more logs to review or to replicate the issue live. I pointed them to this as well as a related thread in hopes they can communicate internally [better] about the plethora of logs they likely already have on this issue.

REQUEST: If you are currently experiencing this Not Responding/Inability to Answer an Interaction in the Embedded client issue and have a Case open with Genesys Support, please add your Case number to this thread so we can combine forces to help Support see just how many issues and examples there already are out there. Individually we'll spin our wheels, but together perhaps we can get some traction.

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------

Hi all, just bumping this thread with some info.

I had Genesys double our Edge count for testing for 2 weeks. I also removed our CRM API calls so we could be sure we were testing a clean Genesys call flow. We did not see any improvement in the area of "unanswerable" calls unfortunately. We are still working with support on extensive log capturing and testing, but are realistically no closer than we have been to a solution. Just wanted to test the waters and see how others are doing.

------------------------------
Scott Tucker
GSG - Graphic Solutions Group Inc.

Original Message:
Sent: 09-11-2023 23:21
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

First @Linda Greenshields, I'm glad you've found some relief from the webrtc pop-up closing whether it's via the workaround or a recent release.

I do find it interesting that release fixed your issue though given:

1. Their description in the 8/30 release notes doesn't mention anything about fixing the webrtc issue.
2. We use the Genesys Cloud for Salesforce embedded client, so there is no "chrome extension" for us to update per se (i.e. we have never had our users install the "Genesys Cloud for Chrome Extension" given the embedded client is built into Salesforce.)

Ironically though, my support engineer just shared similar information in my current case regarding the webrtc pop-up window issue, but referenced the 9/6 release--the release notes for which also do not mention addressing the webrtc pop-up issue. C'mon Genesys...we need all the deets:

"The development team is still investigating the [Not Responding/Inability to answer calls] issue in the case. I did want to mention however that the development team has released a deployment for the CRM to address the Chrome feature on September 6th."

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 09-11-2023 18:06
From: Linda Greenshields
Subject: ServiceNow Connector - Agents unable to answer calls

Hi Everyone,

Just an update on my specific embedded-client issue (in Service Now using Chrome), where agents were unable to answer or initiate calls using the softphone widget due to the WebRTC popup window closing:

I had the work around in place (shared by Brian way back in entry 20) and I noticed among the weekly updates from Genesys on 8/30 this "Genesys Cloud for Chrome extension update." I asked the Genesys engineer with my ticket if that update was a fix for my disappearing WebRTC popup.  He said it was but they had to roll it back.  Oops?  He later let me know it it had been pushed out again and asked me to test it (without the work around in place).  I did this and, so far so good.

So for anyone experiencing that specific issue with their embedded client in Chrome, maybe this will help you too.

Linda

------------------------------
LindaGreenshields
New York University

Original Message:
Sent: 08-31-2023 16:10
From: Brian Jones
Subject: ServiceNow Connector - Agents unable to answer calls

@ALL - Genesys is still digging into our logs and has made mention they will likely need more logs to review or to replicate the issue live. I pointed them to this as well as a related thread in hopes they can communicate internally [better] about the plethora of logs they likely already have on this issue.

REQUEST: If you are currently experiencing this Not Responding/Inability to Answer an Interaction in the Embedded client issue and have a Case open with Genesys Support, please add your Case number to this thread so we can combine forces to help Support see just how many issues and examples there already are out there. Individually we'll spin our wheels, but together perhaps we can get some traction.

------------------------------
Brian T. Jones | Ascension | Senior Specialist - Technology

Original Message:
Sent: 02-22-2023 13:00
From: John Anaya
Subject: ServiceNow Connector - Agents unable to answer calls

We have a situation that has been increasing since we installed PureCloud.  We have a number of interactions that are showing as User Not Responding.  The agents try to answer the call in the Connector, but the pressing the answer button doesn't do anything on their Connector.  The Voice Alerting timeout is met and the agent goes Not Responding and the call will bounce to the next agent and is answered.

It is an intermittent issues and does not matter if the agent is setup as WFH or they are in the office, but in a month, we are seeing about 10% of the calls are facing this issue.

Other than network/console logs, there is not much we can send to support.  Running a constant Wireshark on an Agent PC drags down the performance of the machine.

Has anyone else seen this issue?

#SIP/VolP

------------------------------
John Anaya
Amdocs Management Limited
------------------------------