Genesys Cloud - Main

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi Kevin, 

Thank you for your reply. You mentioned that the significant changes in the way the edges handle the IceI dle timeouts have changed, my concern is that we are seeing call disconnects with that error. 

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Yes. The main point of the other thread (kind of buried in there) is that these call disconnects have been happening all along due to network issues, and now you are seeing them because the system now reports them more accurately. 

Hi Kevin, 

Thank you for your reply. You mentioned that the significant changes in the way the edges handle the IceI dle timeouts have changed, my concern is that we are seeing call disconnects with that error. 

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Thank you for your response. It is helpful to know that the system is now reporting call disconnects more accurately. However, we've noticed an increase in client-reported dropped calls since this change. Could you clarify why this might be the case? Even prior to the new error reporting, clients were already reporting dropped calls when they occurred.

Yes. The main point of the other thread (kind of buried in there) is that these call disconnects have been happening all along due to network issues, and now you are seeing them because the system now reports them more accurately. 

Hi Kevin, 

Thank you for your reply. You mentioned that the significant changes in the way the edges handle the IceI dle timeouts have changed, my concern is that we are seeing call disconnects with that error. 

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

I don't have specific extra information, unfortunately. You may want to open a Support case to be added to their list of people experiencing increased disconnects and get updates

Thank you for your response. It is helpful to know that the system is now reporting call disconnects more accurately. However, we've noticed an increase in client-reported dropped calls since this change. Could you clarify why this might be the case? Even prior to the new error reporting, clients were already reporting dropped calls when they occurred.

Yes. The main point of the other thread (kind of buried in there) is that these call disconnects have been happening all along due to network issues, and now you are seeing them because the system now reports them more accurately. 

Hi Kevin, 

Thank you for your reply. You mentioned that the significant changes in the way the edges handle the IceI dle timeouts have changed, my concern is that we are seeing call disconnects with that error. 

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

I'll add that we have received an increase in reports from agents and callers about calls being dropped mid-conversation.  We ingest the Genesys Operational Console data into Sumologic and the following events hadn't been triggered until around Sept. 24th/25th.  We have noticed this on 2 different Orgs, on two different Edge versions - 1.0.0.26833 and 1.0.0.29200.  I'm not sure why our primary org is still on 1.0.0.26833.

• TELEPHONY-0007 (Endpoint ICE Negotiation Failed)
• TELEPHONY-0010 (WebRTC ICE Idle Detected)
• TELEPHONY-0011 (DTLS Peer Disconnect)

Even if logic was added to better log these events, it doesn't explain why dropped calls would have increased.

I don't have specific extra information, unfortunately. You may want to open a Support case to be added to their list of people experiencing increased disconnects and get updates

Thank you for your response. It is helpful to know that the system is now reporting call disconnects more accurately. However, we've noticed an increase in client-reported dropped calls since this change. Could you clarify why this might be the case? Even prior to the new error reporting, clients were already reporting dropped calls when they occurred.

Yes. The main point of the other thread (kind of buried in there) is that these call disconnects have been happening all along due to network issues, and now you are seeing them because the system now reports them more accurately. 

Hi Kevin, 

Thank you for your reply. You mentioned that the significant changes in the way the edges handle the IceI dle timeouts have changed, my concern is that we are seeing call disconnects with that error. 

Hi Ninette,

There have been significant changes in the way the edges handle the iceIdle timeouts. previously you may not even have noticed as they did not appear on regular performance views. They are now reported, depending when your edges were updated. see this thread :-

Genesys Cloud - Main - Genesys

hope that helps,

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

#Telephony

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

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

#Telephony

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

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi Ninette,

Thanks for the update.

One of my customer raised this issue today and I will do some research into the topic, I will get back to you in a few days.

Thanks

James

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi James, thank you.

There is another thread for this issue: https://community.genesys.com/discussion/telephony-0010-and-telephony-0011-events-recently-started

Hi Ninette,

Thanks for the update.

One of my customer raised this issue today and I will do some research into the topic, I will get back to you in a few days.

Thanks

James

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Hi all,

we're also seeing this increase in the number of those events that have been reported to us.

There is also a group policy mentioned on Win11 - does anyone know which group policy that is?

Regards,
Christian

Hi James, thank you.

There is another thread for this issue: https://community.genesys.com/discussion/telephony-0010-and-telephony-0011-events-recently-started

Hi Ninette,

Thanks for the update.

One of my customer raised this issue today and I will do some research into the topic, I will get back to you in a few days.

Thanks

James

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

You should contact Support to get all the details on that one

Hi all,

we're also seeing this increase in the number of those events that have been reported to us.

There is also a group policy mentioned on Win11 - does anyone know which group policy that is?

Regards,
Christian

Hi James, thank you.

There is another thread for this issue: https://community.genesys.com/discussion/telephony-0010-and-telephony-0011-events-recently-started

Hi Ninette,

Thanks for the update.

One of my customer raised this issue today and I will do some research into the topic, I will get back to you in a few days.

Thanks

James

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

Will try to get this Group Policy.

------------------------------
Christian Rosenberger
System Architekt Customer Interaction Art

Original Message:
Sent: 10-08-2025 07:43
From: George Ganahl
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

You should contact Support to get all the details on that one

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

Original Message:
Sent: 10-08-2025 06:50
From: Christian Rosenberger
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hi all,

we're also seeing this increase in the number of those events that have been reported to us.

There is also a group policy mentioned on Win11 - does anyone know which group policy that is?

Regards,
Christian

------------------------------
Christian Rosenberger
System Architekt Customer Interaction Art

Original Message:
Sent: 10-07-2025 12:52
From: Ninette Elashry
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hi James, thank you.

There is another thread for this issue: https://community.genesys.com/discussion/telephony-0010-and-telephony-0011-events-recently-started

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

Original Message:
Sent: 10-07-2025 12:29
From: James Brannigan
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hi Ninette,

Thanks for the update.

One of my customer raised this issue today and I will do some research into the topic, I will get back to you in a few days.

Thanks

James

------------------------------
James Brannigan
Senior Technical Account Manager

Original Message:
Sent: 10-07-2025 12:24
From: Ninette Elashry
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hello James, thank you for your response. 

I agree that, officially, there has been no mention of a change to the IceIdle timeout. However, we've recently observed a new disconnect type in the Interaction Details view: "Internal Participant: disconnect reason: Error." In the main view, this corresponds to "Disconnect type: System."

In this thread and others, several people have mentioned a change in how the Edge reports this error, which is why I wanted to confirm.

Previously, agents did not see this error message appear on their screens. Now, we're receiving multiple reports from different organizations where agents are seeing this error pop up and experiencing dropped calls, even though no network changes have been made on their side.

We've opened several cases with Support, and the response so far indicates that the error appears due to the 10-second timeout.

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

Original Message:
Sent: 10-07-2025 04:57
From: James Brannigan
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hi Ninette,

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update? Where did you see this information. Genesys has only provided 2 edge updates since June and there has been no mention of changes to the iceidle timeout.

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds? As far as I know, it has always been 10 seconds but Genesys support can confirm if it has changed.

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior? - Yes calls would disconnect and the erorr iceidle would be visible.

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before? I have not seen any evidence of more dropped calls with my customers, if ye have noticed an increase in droppped calls then it is worth raising this issue with our support team.

Have you opened a case with Genesys support?

Thanks

James

------------------------------
James Brannigan
Senior Technical Account Manager

Original Message:
Sent: 10-06-2025 11:56
From: Ninette Elashry
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hello James,

Thank you for the information. From the discussion thread, I understand that there have been significant changes in how the Edges handle IceIdle timeouts. Could you please clarify the following points?

1. When did this change occur, and in which Edge version was it introduced? Also, is there any documentation available on this update?

2. Did this change modify the IceIdle timeout duration, or has it always been set to 10 seconds?

3. Prior to this change, if an IceIdle timeout occurred, did it result in a dropped call, or is that a new behavior?

4. If the change was only to surface or report the new error, why are we now seeing more agents report dropped calls than before?

Thank you for your help in clarifying these details.

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

Original Message:
Sent: 10-03-2025 10:02
From: James Brannigan
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hi Ninette, I

The CEIdleDetection occurs when a user or agent is actively on call and we receive no packets of any kind for 10 seconds from the agent's WebRTC socket. It is categorized as a station error and currently, when it happens, we disconnect the call and tag the User's Disconnect Reason as Endpoint.

This issue can be caused by some of the following reasons.

1. Internet Connection issues - issues with connectivity to our Media Services/Relay(if TURN) can significantly disrupt WeBRTC calls as it relies on a stable and reliable internet connection for real-time audio and data transmission between peers.
2. Third-Party Security Software - antivirus programs with built-in firewalls that can change firewall settings, including closing ports that it deems risky.
   Security Policies - Group Policy Object (GPO) applied in a network environment can override individual machine settings, leading to the unintentional closing of ports.
3. VPN issues - because the Genesys Cloud application relies on multiple services (including Web, Media, and STUN), the selective tunneling of some traffic to the exclusion of others can cause control or media traffic to be received out of sequence. This can lead to dropped calls and sometimes audio issues.
4. Overutilized Local Machine's resources - WebRTC relies on the machine's resources such as CPU, RAM, and network interface to transmit and receive real-time data. If these resources are overutilized, it can negatively impact the performance of WebRTC calls.

Another good approach is to try and capture pcap logs and raise a case with Genesys where they can review the logs and provide a bit more information.

------------------------------
James Brannigan
Senior Technical Account Manager

Original Message:
Sent: 09-29-2025 18:29
From: Ninette Elashry
Subject: Dropped Calls – WebRTC Endpoint Disconnect (Ice Idle Detection)

Hello Community,

We are starting to see an increase in dropped calls with the following error message?

Error Message:

• WebRTC endpoint disconnect

• Reason = Ice Idle Detection

When checking the disconnect reason, it shows as follows:

• Side: Agent (client, error)

• Disconnect type: System

Has anyone else seen this occurring in their org or something similar?  If you have, is there anything you have done to minimize or mitigate this issue?

#Telephony

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