Genesys Cloud - Main

One of my agents began reporting this same issue yesterday afternoon.

One of my agents began reporting this same issue yesterday afternoon.

Hey Shane,

I have seen this happen before and it typically happens when there is an issue with the traffic coming to or leaving Genesys Cloud. If you have made any recent changes to your network, I would recommend rolling them back. We recommend that all traffic related to Genesys Cloud be bypassed or whitelisted.

If you can post the case number that you have opened with Customer Care, I can help monitor the progress on my end as well.

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

All,

We are still chasing this issue as well internally here. This is still very intermittent as mentioned before and we are not able to recreate on-demand. We continue to work with support/care and also internally. Internally we plan to gather more Zscaler logs, deploy AppNeta endpoint monitoring to further assist. 

Our users are working mostly from home and using Zscaler VPN. We are totally bypassing the VPN for media services such as RTP and STUN (our regions CIDR range for media services). We are not bypassing for 443 traffic due to the large number of AWS IP ranges that are in scope and our security team does not want to bypass. We do have SSL packet inspection turned off for our Genesys Cloud regions domain, but it seems at times, I see traffic hitting specific AWS IP's and not the regions domain and we suspect this traffic getting inspected may be leading to our issue. (just a hunch and may not be correct)

Long story short, the mystery continues and we continue to dig-in. If we are able to shed light using AppNeta or by setting up a mirrored port to try and determine what is happening, I'll share back w this thread.

Due to how infrequent it occurs, trying to get a console/network log from the agent is almost impossible. Sorry to report we have no solid answers here yet.

Thanks all, appreciate everyone's feedback!

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Hi @Judy Kerbel, @Shane Jenkins and everyone else in this thread that posted.
Thank you for sharing your feedback.

We've also observed a significant increase in "not responding" interactions since last week, beginning on Sunday, May 4th, and escalating since Wednesday. Like you, we're collaborating with one client setup similar to the one Shane described, but we're facing challenges in capturing the necessary logs at the right time-it often feels like a game of guessing and trying. 

It seems that this problem might be occurring at a global or platform level. We've noticed that it's not confined to a single organization, region, or deployment type. Both On-Premises and BYOC Cloud deployments are affected, suggesting a possible issue with the Web-RTC client.

Support team noted in the ticket that there's no Jingle proceed from the agent, despite auto-answer being enabled on the user's profile, but theyhaven't reached a conclusion yet.

Let's continue sharing our experiences. Thank you all for your contributions.

Best regards,

All,

We are still chasing this issue as well internally here. This is still very intermittent as mentioned before and we are not able to recreate on-demand. We continue to work with support/care and also internally. Internally we plan to gather more Zscaler logs, deploy AppNeta endpoint monitoring to further assist. 

Our users are working mostly from home and using Zscaler VPN. We are totally bypassing the VPN for media services such as RTP and STUN (our regions CIDR range for media services). We are not bypassing for 443 traffic due to the large number of AWS IP ranges that are in scope and our security team does not want to bypass. We do have SSL packet inspection turned off for our Genesys Cloud regions domain, but it seems at times, I see traffic hitting specific AWS IP's and not the regions domain and we suspect this traffic getting inspected may be leading to our issue. (just a hunch and may not be correct)

Long story short, the mystery continues and we continue to dig-in. If we are able to shed light using AppNeta or by setting up a mirrored port to try and determine what is happening, I'll share back w this thread.

Due to how infrequent it occurs, trying to get a console/network log from the agent is almost impossible. Sorry to report we have no solid answers here yet.

Thanks all, appreciate everyone's feedback!

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

We also opened a case with support last week as we saw a huge increase of agents reporting similar issues both working in Salesforce with openCTI and other agents working in the native Geneus Gui with webRTC  with the client not responding when they try to answer a call.

Hi @Judy Kerbel, @Shane Jenkins and everyone else in this thread that posted.
Thank you for sharing your feedback.

We've also observed a significant increase in "not responding" interactions since last week, beginning on Sunday, May 4th, and escalating since Wednesday. Like you, we're collaborating with one client setup similar to the one Shane described, but we're facing challenges in capturing the necessary logs at the right time-it often feels like a game of guessing and trying. 

It seems that this problem might be occurring at a global or platform level. We've noticed that it's not confined to a single organization, region, or deployment type. Both On-Premises and BYOC Cloud deployments are affected, suggesting a possible issue with the Web-RTC client.

Support team noted in the ticket that there's no Jingle proceed from the agent, despite auto-answer being enabled on the user's profile, but theyhaven't reached a conclusion yet.

Let's continue sharing our experiences. Thank you all for your contributions.

Best regards,

All,

We are still chasing this issue as well internally here. This is still very intermittent as mentioned before and we are not able to recreate on-demand. We continue to work with support/care and also internally. Internally we plan to gather more Zscaler logs, deploy AppNeta endpoint monitoring to further assist. 

Our users are working mostly from home and using Zscaler VPN. We are totally bypassing the VPN for media services such as RTP and STUN (our regions CIDR range for media services). We are not bypassing for 443 traffic due to the large number of AWS IP ranges that are in scope and our security team does not want to bypass. We do have SSL packet inspection turned off for our Genesys Cloud regions domain, but it seems at times, I see traffic hitting specific AWS IP's and not the regions domain and we suspect this traffic getting inspected may be leading to our issue. (just a hunch and may not be correct)

Long story short, the mystery continues and we continue to dig-in. If we are able to shed light using AppNeta or by setting up a mirrored port to try and determine what is happening, I'll share back w this thread.

Due to how infrequent it occurs, trying to get a console/network log from the agent is almost impossible. Sorry to report we have no solid answers here yet.

Thanks all, appreciate everyone's feedback!

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

For us, A few a few months ago we had an issue where upon login, that genesy would not see that audio permission were granted.
This was only an issue on the first login after restart, and would go away after the user refreshed, and there would be no issues the rest of the day.
If they did not refresh, the system would send them a call but not allow them to answer it, so they would go into not responding.
We alos noticed that if agents did not restart their computers, this error would not occur on their first daily login

Genesys has still not solved that issue.

However like a lot of you it seems, we are now seeing an increase in random throughout the day not respondings starting last week.
Nice (but akso disheartening) to see we are not alone.

We have a mixture of in office and remote agents.
We use WebRTC.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Really appreciate everybody's input on this! Knowing we are not alone is helpful.

We are US West. Is everybody else also in this region? Also wanted to mention we use the desktop app. 

For us, A few a few months ago we had an issue where upon login, that genesy would not see that audio permission were granted.
This was only an issue on the first login after restart, and would go away after the user refreshed, and there would be no issues the rest of the day.
If they did not refresh, the system would send them a call but not allow them to answer it, so they would go into not responding.
We alos noticed that if agents did not restart their computers, this error would not occur on their first daily login

Genesys has still not solved that issue.

However like a lot of you it seems, we are now seeing an increase in random throughout the day not respondings starting last week.
Nice (but akso disheartening) to see we are not alone.

We have a mixture of in office and remote agents.
We use WebRTC.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

For us, A few a few months ago we had an issue where upon login, that genesy would not see that audio permission were granted.
This was only an issue on the first login after restart, and would go away after the user refreshed, and there would be no issues the rest of the day.
If they did not refresh, the system would send them a call but not allow them to answer it, so they would go into not responding.
We alos noticed that if agents did not restart their computers, this error would not occur on their first daily login

Genesys has still not solved that issue.

However like a lot of you it seems, we are now seeing an increase in random throughout the day not respondings starting last week.
Nice (but akso disheartening) to see we are not alone.

We have a mixture of in office and remote agents.
We use WebRTC.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hi!

The times this issue occurred were related to network issues.
When it happens, try running WebRTC Diagnostics in Calls > Settings > Run Diagnostics.

Has anyone received any useful information from open support cases?

Have others tried TIme Machine to revert back to 11.50 or 11.51? Has this helped your users. We have seen some improvement when we try this on a limited number of users but it is not a feasible workaround as it is required for to be rerun every time a user logs on.

@Jason Kleitz Has Genesys determined root cause? Is there a fix in the works? Is there an ETA for a fix.

Our customers are VERY frustrated. Our customer call volume will significantly increase over the next few weeks/months and having agents go into 'not responding' and not be able to answer calls is a major issue.

We have seen number of times agents go into not responding double since some time last week. Users complain that they try to answer calls and cannot.

Steph, sounds very similar to our situation. We are getting this specific issue since afternoon of 5/7. Home network users as well as users connected via VPN and remote sites. Working with support on this issue, but wanted to let you know we are in the same boat.

Marek, is this issue happening with remote users while connected to their home network? 

We are experiencing this since last week. I have opened a ticket with our vendor.

Thanks,

Steph

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

That seems a little misinformed on part of whoever stated the issue is not widespread. Search for "Not Responding" in the community and there are many, many posts about this issue. I think the possible reason there are not many support tickets open is because, like others have stated in this thread, those tickets never end up with a resolution. It usually ends with repeated requests for the same console/network logs or with just being told the issue is on the customer side. 

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

Agreed with Matthew, support tickets have not been helpful in actually getting any help/attention, hence us posting here and elsewhere to try and get SOME attention

That seems a little misinformed on part of whoever stated the issue is not widespread. Search for "Not Responding" in the community and there are many, many posts about this issue. I think the possible reason there are not many support tickets open is because, like others have stated in this thread, those tickets never end up with a resolution. It usually ends with repeated requests for the same console/network logs or with just being told the issue is on the customer side. 

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

Hi Judy,

We have the added wonder of being managed by a Service Provider, so the only way for us to Log a Support Case is to escalate to QPC, who then log a support case on our behalf.

The problem we have is there is no Agent Status report, to show agents being placed into Not Responding.

And then when you manage to snag some data, the response is, "Oh, the agent must have taken themselves off the queue"

The agents are the one's coming to us, they won't report themselves if they were doing the wrong thing,

But because QPC blame agents (it's easier than actually investigating), they won't log a ticket.

I miss our old System where higher level users got direct access to the support portal. and 90% of the tickets logged were responded to within 48 hours.

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

Hi Judy,

We have the added wonder of being managed by a Service Provider, so the only way for us to Log a Support Case is to escalate to QPC, who then log a support case on our behalf.

The problem we have is there is no Agent Status report, to show agents being placed into Not Responding.

And then when you manage to snag some data, the response is, "Oh, the agent must have taken themselves off the queue"

The agents are the one's coming to us, they won't report themselves if they were doing the wrong thing,

But because QPC blame agents (it's easier than actually investigating), they won't log a ticket.

I miss our old System where higher level users got direct access to the support portal. and 90% of the tickets logged were responded to within 48 hours.

I encourage anyone who does not have a support ticket open for this issue to please open one. I am being told this is not widespread as number of cases reported does not match what is seen in this thread. Therefore, this also does not warrant any mention on status page.

We started experincing the issue last Wednesday (5/7) afternoon as well. We made the changes for CIDR back in October and running the network test shows its passing and not seeing any issues with the network tests. Its been intermittent for us, users on and off our VPN, on and off Wi-Fi. 

Is anyone experiencing the issue also do the rollout for the Multi-Context Pane?

We have made these changes and still are seeing the same impact, so the new CIDR range is not the problem for us

Hello all,

If you did not check out this Resource Center article, I would highly recommend checking with your Network Team to make sure that your organization made the appropriate changes for the CIDR expansion. Based on reading some of the responses in this thread and checking with some of our internal conversations, some of the issues may be related to the CIDR expansion rollout.

https://help.mypurecloud.com/announcements/2024-genesys-cidr-expansion-commercial/

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

Do you have any information as to when the fix for the issue with Chromium will be rolled out? Switching our users to Firefox is not really an option.

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

Do you have any information as to when the fix for the issue with Chromium will be rolled out? Switching our users to Firefox is not really an option.

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

@ Jason Could you provide more information about the bug?

Our security has only approved Edge as this is strictly managed by our Client Tech Team and we have security policies in place to block any other browsers. 

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

@Jason Kleitz, is it a Chromium defect or Genesys Cloud defect you refer to? Possible to share some more details, please?

------------------------------
Timo Valimaki
Solution architect
------------------------------


Original Message:
Sent: 05-14-2025 15:00
From: Jason Kleitz
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

------------------------------
Jason Kleitz
Online Community Manager/Moderator

Hello,

Based on the info that I've seen, this appears to be an issue with Chromium and not Genesys and should now be fixed with the most recent version of the browser update. The update should also be out for the Edge browser as well.

------------------------------
Jason Kleitz
Online Community Manager/Moderator
------------------------------


Original Message:
Sent: 05-17-2025 03:16
From: Timo Valimaki
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

@Jason Kleitz, is it a Chromium defect or Genesys Cloud defect you refer to? Possible to share some more details, please?

------------------------------
Timo Valimaki
Solution architect


Original Message:
Sent: 05-14-2025 15:00
From: Jason Kleitz
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

------------------------------
Jason Kleitz
Online Community Manager/Moderator

Hello,

Based on the info that I've seen, this appears to be an issue with Chromium and not Genesys and should now be fixed with the most recent version of the browser update. The update should also be out for the Edge browser as well.

------------------------------
Jason Kleitz
Online Community Manager/Moderator
------------------------------


Original Message:
Sent: 05-17-2025 03:16
From: Timo Valimaki
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

@Jason Kleitz, is it a Chromium defect or Genesys Cloud defect you refer to? Possible to share some more details, please?

------------------------------
Timo Valimaki
Solution architect


Original Message:
Sent: 05-14-2025 15:00
From: Jason Kleitz
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

Hello all,

I've been digging into this a bit more. If you are using a Chromium based browser (such as Chrome or Edge), could you see if using Firefox helps alleviate the issue? There may have been an issue with Chromium that has been fixed and not rolled out yet for those web browsers.

------------------------------
Jason Kleitz
Online Community Manager/Moderator

Interesting, we had a consultant who claimed that as soon as every call finished, the system was putting her in Meal Break Status, she had to manually put herself in available after each call. Problem is it was occuring from 19:40 - 23:00 on a night shift when no-one was here, and it didn't occur again.

So we never put a ticket, because it was something so random!.

------------------------------
Wayde Masters
Demand Forecasting & Resource Officer
------------------------------

Interesting, we had a consultant who claimed that as soon as every call finished, the system was putting her in Meal Break Status, she had to manually put herself in available after each call. Problem is it was occuring from 19:40 - 23:00 on a night shift when no-one was here, and it didn't occur again.

So we never put a ticket, because it was something so random!.

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

We have seen a similar issue at our organization (US West region). We noticed it today, but now seeing others have had the same issues it appears we aren't the only ones so I'm adding my name to the list. Who knows how long this has been happening with it not being caught by us. A ticket was opened with Genesys to investigate. 

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

Hello,

I have spoken to most affected users from our organization and it seems like the issue has been resolved for us.

What have changed since last week, is that Edge got a new version, here's release notes:

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Fixed various bugs and performance issues.

Stable channel security updates are listed here.

Please verify if you have the latest release.

We have seen a similar issue at our organization (US West region). We noticed it today, but now seeing others have had the same issues it appears we aren't the only ones so I'm adding my name to the list. Who knows how long this has been happening with it not being caught by us. A ticket was opened with Genesys to investigate. 

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

Our users are already on this version of Edge and we have not seen any improvement.

Hello,

I have spoken to most affected users from our organization and it seems like the issue has been resolved for us.

What have changed since last week, is that Edge got a new version, here's release notes:

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Fixed various bugs and performance issues.

Stable channel security updates are listed here.

Please verify if you have the latest release.

We have seen a similar issue at our organization (US West region). We noticed it today, but now seeing others have had the same issues it appears we aren't the only ones so I'm adding my name to the list. Who knows how long this has been happening with it not being caught by us. A ticket was opened with Genesys to investigate. 

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

Hello,

We're experiencing the same issue in our operation, using Genesys Cloud integrated with Salesforce.

Agents with Auto-Answer enabled are going into "Not Responding" status without ever being alerted to an incoming interaction. We opened a ticket, and after some investigation, we identified that browser tab sleep behavior was interfering with WebRTC session readiness.

Specifically, when the Salesforce tab is not in focus, the browser may suspend it, preventing media initialization and blocking the Auto-Answer trigger.

As a mitigation, we implemented GPO policies to exclude the Salesforce and Genesys Cloud domains from tab suspension in Chrome, Edge, and Firefox. We're still monitoring the results over the next few days. 

Has anyone here tried similar adjustments, or found other effective solutions?

Our users are already on this version of Edge and we have not seen any improvement.

Hello,

I have spoken to most affected users from our organization and it seems like the issue has been resolved for us.

What have changed since last week, is that Edge got a new version, here's release notes:

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Fixed various bugs and performance issues.

Stable channel security updates are listed here.

Please verify if you have the latest release.

We have seen a similar issue at our organization (US West region). We noticed it today, but now seeing others have had the same issues it appears we aren't the only ones so I'm adding my name to the list. Who knows how long this has been happening with it not being caught by us. A ticket was opened with Genesys to investigate. 

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

We continue to investigate the randomness we are seeing. So far still nothing solid/concrete.

I do have a question for those of you have have GPO in place for sleeping tabs (we mostly use Chrome and Edge. What logic/entries are you adding via GPO to help avoid sleeping tabs?

I primarily am asking because I've seen two different entries for Genesys Cloud and Chrome. I'm not sure if we should use both or as long as we have one or the other, we should be good? We are FedRAMP, so use2 is our region.

Example 1: (Per Genesys document in resource center) https://help.mypurecloud.com/articles/disable-your-browsers-sleep-mode-setting/

use2.us-gov-pure.cloud

Example 2: (https://chromeenterprise.google/policies/url-patterns/) This approach uses [*.] in front of the region / domain

[*.]use2.us-gov-pure.cloud 

Any suggestions or evidence you may have on which logic above we truly need to apply? 

Thanks again,

Hello,

We're experiencing the same issue in our operation, using Genesys Cloud integrated with Salesforce.

Agents with Auto-Answer enabled are going into "Not Responding" status without ever being alerted to an incoming interaction. We opened a ticket, and after some investigation, we identified that browser tab sleep behavior was interfering with WebRTC session readiness.

Specifically, when the Salesforce tab is not in focus, the browser may suspend it, preventing media initialization and blocking the Auto-Answer trigger.

As a mitigation, we implemented GPO policies to exclude the Salesforce and Genesys Cloud domains from tab suspension in Chrome, Edge, and Firefox. We're still monitoring the results over the next few days. 

Has anyone here tried similar adjustments, or found other effective solutions?

Our users are already on this version of Edge and we have not seen any improvement.

Hello,

I have spoken to most affected users from our organization and it seems like the issue has been resolved for us.

What have changed since last week, is that Edge got a new version, here's release notes:

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Fixed various bugs and performance issues.

Stable channel security updates are listed here.

Please verify if you have the latest release.

We have seen a similar issue at our organization (US West region). We noticed it today, but now seeing others have had the same issues it appears we aren't the only ones so I'm adding my name to the list. Who knows how long this has been happening with it not being caught by us. A ticket was opened with Genesys to investigate. 

We've been seeing this issue on our end as well. Agents are set to auto answer calls but sometimes the alert will timeout, resulting for the interaction to be offered to another agent. Then, the previous agent's status will suddenly change to "Not Responding."

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie
------------------------------


Original Message:
Sent: 05-23-2025 14:53
From: Matthew Pleus
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

The microphone becoming available is a big issue we see with this as well. 

------------------------------
[Matt] [Pleus]
[Business Systems Analyst]


Original Message:
Sent: 05-22-2025 12:54
From: Johannes Froehlich
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie

Hello,

We're facing the same issue, agents going into "Not Responding" even with the auto-answer enabled.

After extensive testing, we've identified a specific pattern:

• It mostly happens right after agents log in: the first call offered after login frequently results in "Not Responding."

• It can persist for multiple calls after login before eventually stabilizing.

• We've confirmed this is not related to network instability, as it occurs even in regions with excellent connectivity and low RTT/latency.

What we've done so far:

• WebRTC Troubleshooter tests: Successful results, even in affected agents.

• Persistent connection configuration: We're currently testing agents with persistent connection disabled, even though our previous timeout was already 14400s.

We'd like to know if anyone else has noticed this post-login pattern and if there are any recommendations from Genesys or the community to mitigate this behavior.

------------------------------
Eduardo Souza
------------------------------


Original Message:
Sent: 06-04-2025 09:45
From: Johannes Froehlich
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie


Original Message:
Sent: 05-23-2025 14:53
From: Matthew Pleus
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

The microphone becoming available is a big issue we see with this as well. 

------------------------------
[Matt] [Pleus]
[Business Systems Analyst]


Original Message:
Sent: 05-22-2025 12:54
From: Johannes Froehlich
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie

Hello,

We're facing the same issue, agents going into "Not Responding" even with the auto-answer enabled.

After extensive testing, we've identified a specific pattern:

• It mostly happens right after agents log in: the first call offered after login frequently results in "Not Responding."

• It can persist for multiple calls after login before eventually stabilizing.

• We've confirmed this is not related to network instability, as it occurs even in regions with excellent connectivity and low RTT/latency.

What we've done so far:

• WebRTC Troubleshooter tests: Successful results, even in affected agents.

• Persistent connection configuration: We're currently testing agents with persistent connection disabled, even though our previous timeout was already 14400s.

We'd like to know if anyone else has noticed this post-login pattern and if there are any recommendations from Genesys or the community to mitigate this behavior.

------------------------------
Eduardo Souza
------------------------------


Original Message:
Sent: 06-04-2025 09:45
From: Johannes Froehlich
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie


Original Message:
Sent: 05-23-2025 14:53
From: Matthew Pleus
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

The microphone becoming available is a big issue we see with this as well. 

------------------------------
[Matt] [Pleus]
[Business Systems Analyst]


Original Message:
Sent: 05-22-2025 12:54
From: Johannes Froehlich
Subject: Agents randomly going into Not Responding status without being alerted to an Interaction and other oddities

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

------------------------------
Johannes Froehlich
Director ICT Communication Services Operations EMEA, UK, Ie

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

Hi everyone, quick update on our side:

Even after adjusting the alert timeout and disabling the persistent connection, we've seen no significant improvement in behavior.

Our agents are still struggling to answer calls, even when the agent clicks "Answer" manually, the media session fails to establish (both with and without auto-answer enabled). We've also observed the following warning in logs: "warn [webrtc-sdk] Permission was denied for media type. Setting sdk state"

This occurs despite the browser (Chrome/Edge) being set to "Always allow" microphone access for both Genesys and Salesforce domains.

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

We are currently experiencing intermittent RONA (Redirect On No Answer) issues affecting multiple agents across various locations. These issues occur regardless of whether agents are working from home or from the office.

Our organization operates two separate Genesys Cloud environments-one based in India and the other in the US  region. Notably, the RONA issues are being observed across both instances, indicating that the problem is not isolated to a single region or deployment.

We have already raised a Genesys Care support request, but the issue has been ongoing for over a month without resolution.

As part of our ongoing troubleshooting efforts, we have already shared Wireshark captures, network diagnostics, browser console logs, and system performance screenshots with the Genesys support team.

We kindly request that the Genesys team prioritize this issue and assist us in identifying and implementing a fix as soon as possible.

Hi everyone, quick update on our side:

Even after adjusting the alert timeout and disabling the persistent connection, we've seen no significant improvement in behavior.

Our agents are still struggling to answer calls, even when the agent clicks "Answer" manually, the media session fails to establish (both with and without auto-answer enabled). We've also observed the following warning in logs: "warn [webrtc-sdk] Permission was denied for media type. Setting sdk state"

This occurs despite the browser (Chrome/Edge) being set to "Always allow" microphone access for both Genesys and Salesforce domains.

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

Hi Deepa Subramanyam,

Can you advise how to determine how many calls are RONA in the Genesys Native reporting?

Or is this something we need an API to discover?

Many Thanks

We are currently experiencing intermittent RONA (Redirect On No Answer) issues affecting multiple agents across various locations. These issues occur regardless of whether agents are working from home or from the office.

Our organization operates two separate Genesys Cloud environments-one based in India and the other in the US  region. Notably, the RONA issues are being observed across both instances, indicating that the problem is not isolated to a single region or deployment.

We have already raised a Genesys Care support request, but the issue has been ongoing for over a month without resolution.

As part of our ongoing troubleshooting efforts, we have already shared Wireshark captures, network diagnostics, browser console logs, and system performance screenshots with the Genesys support team.

We kindly request that the Genesys team prioritize this issue and assist us in identifying and implementing a fix as soon as possible.

Hi everyone, quick update on our side:

Even after adjusting the alert timeout and disabling the persistent connection, we've seen no significant improvement in behavior.

Our agents are still struggling to answer calls, even when the agent clicks "Answer" manually, the media session fails to establish (both with and without auto-answer enabled). We've also observed the following warning in logs: "warn [webrtc-sdk] Permission was denied for media type. Setting sdk state"

This occurs despite the browser (Chrome/Edge) being set to "Always allow" microphone access for both Genesys and Salesforce domains.

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

We are currently experiencing intermittent RONA (Redirect On No Answer) issues affecting multiple agents across various locations. These issues occur regardless of whether agents are working from home or from the office.

Our organization operates two separate Genesys Cloud environments-one based in India and the other in the US  region. Notably, the RONA issues are being observed across both instances, indicating that the problem is not isolated to a single region or deployment.

We have already raised a Genesys Care support request, but the issue has been ongoing for over a month without resolution.

As part of our ongoing troubleshooting efforts, we have already shared Wireshark captures, network diagnostics, browser console logs, and system performance screenshots with the Genesys support team.

We kindly request that the Genesys team prioritize this issue and assist us in identifying and implementing a fix as soon as possible.

Hi everyone, quick update on our side:

Even after adjusting the alert timeout and disabling the persistent connection, we've seen no significant improvement in behavior.

Our agents are still struggling to answer calls, even when the agent clicks "Answer" manually, the media session fails to establish (both with and without auto-answer enabled). We've also observed the following warning in logs: "warn [webrtc-sdk] Permission was denied for media type. Setting sdk state"

This occurs despite the browser (Chrome/Edge) being set to "Always allow" microphone access for both Genesys and Salesforce domains.

We checked for Microphone availability (ensure always allowed) and browser tab sleep mode

Further we currently changed the settings for persistent timer for several user.

Standard 600 changed for several to 14400 and another group is disabled.  Will take a few days to see if this does change any.

If anyone might try to confirm / check

The microphone becoming available is a big issue we see with this as well. 

We experience this for about 3% of our calls shown Not Responsive on Global User Base. Office and Home Office and autoanswer as well manual accept. One finding was that the microphone became unavailbale hence the WebRTC request was directly taken back. We are looking for such events to proof if this is a direction pointing to the issue.  

Hi all,

Since the last comment in this thread, I've noticed several new discussions about the same topic, which indicates that the problem with "not responding" is recurring and persistent.

We've been facing ongoing challenges with intermittent "not responding" issues during voice calls in the native Genesys Cloud UI. Despite following best practices related to bandwidth, browser configuration, and agent PC specifications, the problem continues to appear in unpredictable ways.

In our communication with Genesys Support, the most recent update we received stated:

"This appears to be a combination of the user's PC performance and/or network slowness (or one leading to the other), where messages from the cloud are not reaching the user immediately and the client is taking too long to respond."

This again points to the idea that from the Genesys perspective, these issues are always attributed to the customer environment-even when the customer is an enterprise, not a startup with "my nephew set up the network" type of infrastructure.

You've probably seen the recent announcement from Microsoft, introducing a dedicated desktop app for their Dynamics 365 Contact Center platform-not just a UI shell, but a separate native voice engine. The reasoning behind this move is clear: while browsers are convenient, they are not yet robust enough to consistently handle real-time media, especially under enterprise workloads.

This validates what many of us in the field have suspected:

"Voice issues are not always due to bad networks or slow PCs-they're often a result of pushing real-time audio through a fragile, multi-purpose browser runtime."

While Genesys has often suggested that these problems stem from customer-side infrastructure, it's not always realistic to expect every agent to operate on a high-end machine with flawless conditions. Even minor fluctuations in browser memory, tab crashes, or device permission errors can easily lead to dropped or delayed calls.

Let me be clear-we strongly support the pure cloud model, without the need for specialized software installations. However, this model needs to be realistically adaptable to the environments in which contact centers operate today.

These ongoing issues highlight a critical gap between the cloud-native vision and operational reality. Browsers were never originally built for enterprise-grade real-time media handling, and some of the issues we're seeing-audio dropouts, delayed connects, or "not responding" agent states-may stem from fundamental browser limitations, not just infrastructure quality.

I'm not suggesting that D365 Contact Center is a better product (because frankly, it's not), but the fact that after just one year, Microsoft acknowledged this issue and delivered a dedicated voice runtime should be a signal to all of us. It's not a step away from cloud-it's a step toward making cloud more resilient.

We believe it's important for Genesys to acknowledge these challenges more openly, and to consider complementary approaches-such as native voice runtimes or modular desktop components-that could enhance stability without compromising the core cloud-native foundation.

Looking forward to hearing perspectives from both the community and the Genesys team.

Warm regards

RASKO

In our organization, we are utilizing AWS route tags to filter region-specific routes, following Genesys' recommendations. However, we've observed that the same Genesys media IPs are being learned from two different regions. It's currently unclear how Genesys handles this scenario, and we suspect this may be contributing to the ongoing RONA issues.

We are actively working with both our BYOC provider and the Genesys team to gain clarity on the correct configuration and to identify any discrepancies. Further investigation is underway to determine the appropriate routing behavior and ensure alignment with Genesys' best practices.

We request GEnesys to look into this on priority and  help customer with right  solution

Hi all,

Since the last comment in this thread, I've noticed several new discussions about the same topic, which indicates that the problem with "not responding" is recurring and persistent.

We've been facing ongoing challenges with intermittent "not responding" issues during voice calls in the native Genesys Cloud UI. Despite following best practices related to bandwidth, browser configuration, and agent PC specifications, the problem continues to appear in unpredictable ways.

In our communication with Genesys Support, the most recent update we received stated:

"This appears to be a combination of the user's PC performance and/or network slowness (or one leading to the other), where messages from the cloud are not reaching the user immediately and the client is taking too long to respond."

This again points to the idea that from the Genesys perspective, these issues are always attributed to the customer environment-even when the customer is an enterprise, not a startup with "my nephew set up the network" type of infrastructure.

You've probably seen the recent announcement from Microsoft, introducing a dedicated desktop app for their Dynamics 365 Contact Center platform-not just a UI shell, but a separate native voice engine. The reasoning behind this move is clear: while browsers are convenient, they are not yet robust enough to consistently handle real-time media, especially under enterprise workloads.

This validates what many of us in the field have suspected:

"Voice issues are not always due to bad networks or slow PCs-they're often a result of pushing real-time audio through a fragile, multi-purpose browser runtime."

While Genesys has often suggested that these problems stem from customer-side infrastructure, it's not always realistic to expect every agent to operate on a high-end machine with flawless conditions. Even minor fluctuations in browser memory, tab crashes, or device permission errors can easily lead to dropped or delayed calls.

Let me be clear-we strongly support the pure cloud model, without the need for specialized software installations. However, this model needs to be realistically adaptable to the environments in which contact centers operate today.

These ongoing issues highlight a critical gap between the cloud-native vision and operational reality. Browsers were never originally built for enterprise-grade real-time media handling, and some of the issues we're seeing-audio dropouts, delayed connects, or "not responding" agent states-may stem from fundamental browser limitations, not just infrastructure quality.

I'm not suggesting that D365 Contact Center is a better product (because frankly, it's not), but the fact that after just one year, Microsoft acknowledged this issue and delivered a dedicated voice runtime should be a signal to all of us. It's not a step away from cloud-it's a step toward making cloud more resilient.

We believe it's important for Genesys to acknowledge these challenges more openly, and to consider complementary approaches-such as native voice runtimes or modular desktop components-that could enhance stability without compromising the core cloud-native foundation.

Looking forward to hearing perspectives from both the community and the Genesys team.

Warm regards

RASKO

Hello everyone,

I wanted you to know that we collaborated with leadership to make sure we addressed this thread with the most relevant information. Below is the response from leadership.

Genesys Community,

Thank you for being a valued customer or partner.

We are constantly testing and monitoring overall performance of our platform including UI performance, in as many realistic customer configurations as we can. We can't test them all so we truly appreciate when customers can share with us what they are encountering with corresponding data, and we target addressing them as quickly as possible. Not responding can be a symptom of a variety of underlying issues.  Genesys Care is available 24/7/365 to assist our customers with triage and pinpointing the root cause.

As part of the case creation, here are some helpful tips:

• Have ready the date & time of the incident along with UserID of the impacted agent(s).
• If possible, coordinate a live session with the impacted agent(s) to collect logs to aide Genesys Care in classifying all events occurring at the time specific to the browser/local machine.

• Note: Please refer to the following article to assist in gathering console logs through our Automatic, On Demand and Manual options:  https://help.mypurecloud.com/articles/gather-console-logs/.

• Consider creating an Alert Rule to be proactively notified when an agent is placed in Not Responding for > X seconds.

• Note: Please refer to the following article to assist in setting up an Alert Rule: https://help.mypurecloud.com/articles/create-alert-rule/.

In certain cases, you may be asked to triage other network related events withing your environment such as:

• VPN connects / reconnects
• Local and cloud-based security tools enabled on the machine
• Internet connectivity, varying based on agent location of work from home or in office

To assist with VPN reconnects during an active WebRTC call, Genesys has two features that will be releasing here in August 2025:

• Graceful media stream recovery of WebRTC calls = https://genesyscloud.ideas.aha.io/ideas/TEL-I-428
• Establish persistent connection when an agent goes on queue (includes attempts to automatically restore persistent connection if connection is temporarily disrupted and aiding in reduction of Not Responding) = https://genesyscloud.ideas.aha.io/ideas/TEL-I-428
• One-click answer from desktop/browser notification (assist in reduction of Not Responding from having multiple browser tabs open and agent not able to locate the correct tab in time before moving to Not Responding) = https://genesyscloud.ideas.aha.io/ideas/INB-I-1070

While there are dozens of technical and environmental configurations that impact overall performance, we have not pinpointed reasons to completely change architecture for how we deliver our UI.  Genesys has a series of UI enhancements underway as part of our ongoing UI/Navigation updates to help streamline and simplify user experience and resource demands.  As always, we value your feedback and welcome continued discussion on this thread by posting your Case Numbers to assist us in further triage.  We also plan to have a live Q&A here in the coming months based on the continued discussion and feedback.

Thank you,

Genesys Community Team