Genesys Cloud - Main

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

Hi Kevin / all,

Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.

Kevin, did you get any indication that Genesys would address this or correct this issue?

Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address? 

I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.

Thanks again all!

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

Hi Kevin / all,

Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.

Kevin, did you get any indication that Genesys would address this or correct this issue?

Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address? 

I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.

Thanks again all!

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

Shane,

Do you receive any errors when running WebRTC phone diagnostics, or does it run successfully and you get a TELEPHONY-0011 event?

Thanks,

Chad

------------------------------
Chad Markle
Senior Director of IT Unified Communications
------------------------------


Original Message:
Sent: 09-30-2025 10:01
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Kevin / all,

Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.

Kevin, did you get any indication that Genesys would address this or correct this issue?

Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address? 

I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.

Thanks again all!

------------------------------
Shane Jenkins


Original Message:
Sent: 09-30-2025 01:42
From: Kevin Young
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com

Hi Chad,

Just tested this on our VPN and off the VPN.

Both scenarios seemed to behave the same. We do get an error as shown in screenshot below, but if we wait it out for 15-20 seconds, we eventually get Test Results and they are positive. We first thought this was something to do w our VPN (Zscaler), but this behavior also occurs off network from our home network. We've had several individuals test this from their home network w same results. We do have supposedly ALL RTP traffic bypassing Zscaler when on network, but again this seems to occur even when not on the VPN.

This also generates the Telephony-0011 event when this occurs.

Are you able to replicate this at all? 

------------------------------
Shane Jenkins
------------------------------


Original Message:
Sent: 10-09-2025 12:18
From: Chad Markle
Subject: Telephony-0010 and Telephony-0011 Events recently started

Shane,

Do you receive any errors when running WebRTC phone diagnostics, or does it run successfully and you get a TELEPHONY-0011 event?

Thanks,

Chad

------------------------------
Chad Markle
Senior Director of IT Unified Communications


Original Message:
Sent: 09-30-2025 10:01
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Kevin / all,

Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.

Kevin, did you get any indication that Genesys would address this or correct this issue?

Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address? 

I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.

Thanks again all!

------------------------------
Shane Jenkins


Original Message:
Sent: 09-30-2025 01:42
From: Kevin Young
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com

We use ZScaler as well and have RTP traffic bypassing it.

I've tried running Diagnostics several times on and off VPN, but I could only get that error message you are getting immediately after disconnecting from the VPN.  If you run the Standalone WebRTC Diagnostics app, do you get that error as well?

Hi Chad,

Just tested this on our VPN and off the VPN.

Both scenarios seemed to behave the same. We do get an error as shown in screenshot below, but if we wait it out for 15-20 seconds, we eventually get Test Results and they are positive. We first thought this was something to do w our VPN (Zscaler), but this behavior also occurs off network from our home network. We've had several individuals test this from their home network w same results. We do have supposedly ALL RTP traffic bypassing Zscaler when on network, but again this seems to occur even when not on the VPN.

This also generates the Telephony-0011 event when this occurs.

Are you able to replicate this at all? 

------------------------------
Shane Jenkins


Original Message:
Sent: 10-09-2025 12:18
From: Chad Markle
Subject: Telephony-0010 and Telephony-0011 Events recently started

Shane,

Do you receive any errors when running WebRTC phone diagnostics, or does it run successfully and you get a TELEPHONY-0011 event?

Thanks,

Chad

------------------------------
Chad Markle
Senior Director of IT Unified Communications


Original Message:
Sent: 09-30-2025 10:01
From: Shane Jenkins
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Kevin / all,

Really appreciate the information and good to know we aren't totally alone in this. We felt pretty strongly that the Edge update led to these new events / errors being reported. We're now getting them hundreds per day and previously we were getting zero of these specific errors. Kind of crazy that we can also recreate at least one of the "errors" on demand by simply running WebRTC phone diagnostics.

Kevin, did you get any indication that Genesys would address this or correct this issue?

Seems like that Edge version introduced or significantly changed how the Edge processes these events. To your point, we also have a trigger and thus are getting email notifications each time these events are generated and we also noticed the disconnect type being ERROR now vs. ENDPOINT for some of them. Just curious if you got a sense this is something Genesys can/will address? 

I'll reach back out to support via our open ticket and ask for additional information and if there are next steps as well. I'll update here if I learn anything more/new.

Thanks again all!

------------------------------
Shane Jenkins


Original Message:
Sent: 09-30-2025 01:42
From: Kevin Young
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Shane,

We have an implementation for a customer that was using the trigger ...user.end to check the conversation.details api for the sip response 480 (IceIdle) on the interact session. We would then be able to perform our own logging to datatable in order to potentially respond back to the customer in a post flow, and to check on agent behavior/network stability, as this event was also signaled if an agent performed a browser refresh while on a call (call avoidance).

This all changed on 26th August for us with the same edge update. (Case #0003863445), and the same  observations as you had above for the operational log. Genesys confirmed these changes.

Unfortunately the event model also changed to report the 480 sip response. The customer segment now shows the 480 sip response in the interact session, which is now immediately disconnected also (previously the customer was still active). The disconnectType for the trigger changed from 'ENDPOINT' to 'ERROR' on the agent side, with an iceIdle WebRtc error code.

hope that helps,

------------------------------
Kevin Young
TTEC Digital, LLC
kevin.young@ttecdigital.com

Hello, 

Same here, we've been experiencing these errors throughout the day for several weeks now.
In our case, we are not a FedRAMP customer, but this issue is also bothering us quite a bit.

Best regards. 

We also seem to have increased reports of WebRTC endpoint disconnect, reason-iceIdleDetection and Failed to rejoin call leg.

Similar to @Judy Kerbel, unsure whether this behaviour always occurred but now is displayed slightly differently in Genesys, therefor have not raised a case with Genesys (yet).

High proportion of our staff work from home.

Our Org is in EU2 running on Edge version 1.0.0.26833.

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

Hi Ernest,

A brief anonymized summary of what was observed..

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

Hi Ernest,

A brief anonymized summary of what was observed..

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the command above, you likely have another bit of software which is triggering the LLDP shutdown.

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

Hi Ernest,

A brief anonymized summary of what was observed..

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

Hi George,

Can you please provide a link of the documentation regarding the Group Policy? Where is this information posted?

Thank you.

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the command above, you likely have another bit of software which is triggering the LLDP shutdown.

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

Hi Ernest,

A brief anonymized summary of what was observed..

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

That is internal info I dug up. I don't know of it being posted anywhere else. Something our folks discovered while working with Microsoft Support

Hi George,

Can you please provide a link of the documentation regarding the Group Policy? Where is this information posted?

Thank you.

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the command above, you likely have another bit of software which is triggering the LLDP shutdown.

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

Hi Ernest,

A brief anonymized summary of what was observed..

Hello Duncan,
what issue in the network they found in particular?

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

Hello George,

Thank you for the information. I believe the following points remain unclear:

• Was there an Edge update that introduced a change in how the IceIdle error is reported?

• Prior to this change, did the IceIdle error result in call disconnects/dropped calls, or was it only visible in the logs?

Thank you for clarifying.

------------------------------
Ninette Elashry
Senior Application Specialist
------------------------------


Original Message:
Sent: 10-07-2025 14:12
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

That is internal info I dug up. I don't know of it being posted anywhere else. Something our folks discovered while working with Microsoft Support

------------------------------
George Ganahl GCCX-AI, GCP, GCSME
Technical Adoption Champion
Genesys
2024 Community Member of the Year


Original Message:
Sent: 10-07-2025 13:38
From: Ninette Elashry
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi George,

Can you please provide a link of the documentation regarding the Group Policy? Where is this information posted?

Thank you.

------------------------------
Ninette Elashry
Senior Application Specialist


Original Message:
Sent: 10-03-2025 10:36
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the command above, you likely have another bit of software which is triggering the LLDP shutdown.

------------------------------
George Ganahl GCCX-AI, GCP, GCSME
Technical Adoption Champion
Genesys
2024 Community Member of the Year


Original Message:
Sent: 10-01-2025 10:43
From: Dan Wong
Subject: Telephony-0010 and Telephony-0011 Events recently started

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

------------------------------
Dan Wong
EUC Engineer


Original Message:
Sent: 10-01-2025 09:01
From: Duncan Lynch
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Ernest,

A brief anonymized summary of what was observed..

------------------------------
Duncan Lynch
Solutions Specialist


Original Message:
Sent: 10-01-2025 08:18
From: Ernest John Nuque
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hello Duncan,
what issue in the network they found in particular?

------------------------------
Ernest John Nuque
Voice Network Engineer


Original Message:
Sent: 09-30-2025 19:53
From: Duncan Lynch
Subject: Telephony-0010 and Telephony-0011 Events recently started

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

------------------------------
Duncan Lynch
Solutions Specialist

Hi, All

We reported this kind of issues, and this is the response of Genesys Support.

Since Edge release: 1.0.0.26833, Organizations will now be able to see the WebRTC disconnect errors logged in the Console. Events such as the Telephony-0010 and 0011.

• This logging was previously not being included or displayed in the Console due to the manner in which Genesys handled WebRTC station sessions during interactions. Since the session handling has been updated with the modern WebRTC feature, this now allows the details for the WebRTC disconnect's Analytics data to be logged and available to you.
• Please keep in mind that the presenting of the errors now do not mean that you are now experiencing "new" issues/errors, but this is more to provide more details regarding what occurred and identifying the disconnect reason.
• Previously you would need to raise these disconnect issue with Support in order for us to identify what caused the disconnect. Now as an Admin in the Organization, you will have more details with those Telephony Events.
  
  

I hope this will be useful :)

BR 

------------------------------
Adrian Rodriguez
------------------------------


Original Message:
Sent: 10-07-2025 15:29
From: Ninette Elashry
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hello George,

Thank you for the information. I believe the following points remain unclear:

• Was there an Edge update that introduced a change in how the IceIdle error is reported?

• Prior to this change, did the IceIdle error result in call disconnects/dropped calls, or was it only visible in the logs?

Thank you for clarifying.

------------------------------
Ninette Elashry
Senior Application Specialist


Original Message:
Sent: 10-07-2025 14:12
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

That is internal info I dug up. I don't know of it being posted anywhere else. Something our folks discovered while working with Microsoft Support

------------------------------
George Ganahl GCCX-AI, GCP, GCSME
Technical Adoption Champion
Genesys
2024 Community Member of the Year


Original Message:
Sent: 10-07-2025 13:38
From: Ninette Elashry
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi George,

Can you please provide a link of the documentation regarding the Group Policy? Where is this information posted?

Thank you.

------------------------------
Ninette Elashry
Senior Application Specialist


Original Message:
Sent: 10-03-2025 10:36
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the command above, you likely have another bit of software which is triggering the LLDP shutdown.

------------------------------
George Ganahl GCCX-AI, GCP, GCSME
Technical Adoption Champion
Genesys
2024 Community Member of the Year


Original Message:
Sent: 10-01-2025 10:43
From: Dan Wong
Subject: Telephony-0010 and Telephony-0011 Events recently started

Thanks for sharing!

Did you find this on all interactions or did it only occur on a certain proportion? 

Was there any particular duration these interaction would eventually "Error" and disconnect?

"This kept happening for approximately 10 seconds..."

Would i be right in staying you saw this in the PCAPs, with multiple Requests / Status every 10 seconds?

------------------------------
Dan Wong
EUC Engineer


Original Message:
Sent: 10-01-2025 09:01
From: Duncan Lynch
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi Ernest,

A brief anonymized summary of what was observed..

------------------------------
Duncan Lynch
Solutions Specialist


Original Message:
Sent: 10-01-2025 08:18
From: Ernest John Nuque
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hello Duncan,
what issue in the network they found in particular?

------------------------------
Ernest John Nuque
Voice Network Engineer


Original Message:
Sent: 09-30-2025 19:53
From: Duncan Lynch
Subject: Telephony-0010 and Telephony-0011 Events recently started

Yes, I reported an increase in these 2 events on 10th September. Genesys investigated and have currently determined the issue is on our side, so the incident is with our network team for investigation.

------------------------------
Duncan Lynch
Solutions Specialist

Hi, All

We reported this kind of issues, and this is the response of Genesys Support.

Since Edge release: 1.0.0.26833, Organizations will now be able to see the WebRTC disconnect errors logged in the Console. Events such as the Telephony-0010 and 0011.

• This logging was previously not being included or displayed in the Console due to the manner in which Genesys handled WebRTC station sessions during interactions. Since the session handling has been updated with the modern WebRTC feature, this now allows the details for the WebRTC disconnect's Analytics data to be logged and available to you.
• Please keep in mind that the presenting of the errors now do not mean that you are now experiencing "new" issues/errors, but this is more to provide more details regarding what occurred and identifying the disconnect reason.
• Previously you would need to raise these disconnect issue with Support in order for us to identify what caused the disconnect. Now as an Admin in the Organization, you will have more details with those Telephony Events.
  
  

I hope this will be useful :)

BR 

------------------------------
Adrian Rodriguez
------------------------------


Original Message:
Sent: 10-07-2025 15:29
From: Ninette Elashry
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hello George,

Thank you for the information. I believe the following points remain unclear:

• Was there an Edge update that introduced a change in how the IceIdle error is reported?

• Prior to this change, did the IceIdle error result in call disconnects/dropped calls, or was it only visible in the logs?

Thank you for clarifying.

------------------------------
Ninette Elashry
Senior Application Specialist


Original Message:
Sent: 10-07-2025 14:12
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

That is internal info I dug up. I don't know of it being posted anywhere else. Something our folks discovered while working with Microsoft Support

------------------------------
George Ganahl GCCX-AI, GCP, GCSME
Technical Adoption Champion
Genesys
2024 Community Member of the Year


Original Message:
Sent: 10-07-2025 13:38
From: Ninette Elashry
Subject: Telephony-0010 and Telephony-0011 Events recently started

Hi George,

Can you please provide a link of the documentation regarding the Group Policy? Where is this information posted?

Thank you.

------------------------------
Ninette Elashry
Senior Application Specialist


Original Message:
Sent: 10-03-2025 10:36
From: George Ganahl
Subject: Telephony-0010 and Telephony-0011 Events recently started

10 seconds matches a recently-discovered issue when Group Policy gets applied to a Windows machine (I think mainly Windows 11) that results in sending sending an LLDP Shutdown message:

"...an LLDP packet which states 'Shutdown LLDP'. This packet causes the NIC on the machine to essentially be reset, and since Genesys Cloud does not currently have any ability to reestablish ICE connectivity after it has been lost the call will simply disconnect."

There is a fix currently in Limited Availability status which will allow for "...graceful media stream recovery for WebRTC calls"

So, when you communicate with Support you might ask about the steps you can take in Group Policy to avoid that particular issue.

To test the effect,

1. On an affected user/machine, perform an outbound WebRTC call from Genesys Cloud.

2. Open cmd.exe as administrator on the machine

3. Run the command 'gpupdate /force'

If the client is affected by this issue, you will see the call disconnect about ten seconds later. If you do not see the call disconnect after running the comm