Genesys Cloud - Main

Hi @Phaneendra Avatapalli

We can check "Disconnect on Idle RTP" option: Use this switch to enable or disable the ability to disconnect a call when RTP is not received for an extended period of time., this switch automatically terminates calls lacking received RTP packets for extended periods

https://help.genesys.cloud/articles/external-trunk-settings/ 

The "Disconnect on Idle RTP" option is available in both:

1. Genesys BYOC Premises Edge (Edge Groups):

• Available: YES
• Location: BYOC Premises Edge group settings
• Default: Enabled
• Description: The Disconnect on Idle RTP switch automatically terminates calls lacking received RTP packets for extended periods

2. BYOC Cloud Trunks (External Trunks):

• Available: YES
• Location: External trunk settings for BYOC Carrier and BYOC PBX trunks
• Default: Enabled
• Description: This switch enables or disables the ability to disconnect a call when RTP is not received for an extended period of time

Timeout Values (same for both):

• 5 minutes for normal calls (bidirectional media)
• 12 hours for media sent in one direction only (unidirectional)

Important Note:
For BYOC Cloud external trunks, this setting is part of the advanced trunk configuration options. While most basic trunk configurations work with default settings, you can access and modify the "Disconnect on Idle RTP" setting when configuring advanced external trunk settings.

Hi Phaneendra,

I think there may actually be two different scenarios hidden behind the same symptom, and distinguishing between them would probably determine the troubleshooting path.

The first thing I would try to confirm is:

During those 1–4 minutes of silence, has the customer actually disconnected from their phone/network already, or are both endpoints still physically connected and simply not speaking?

I ask because conversational silence and idle RTP are not the same thing.

The Genesys Disconnect on Idle RTP setting disconnects the call when RTP is no longer being received for an extended period. For a normal bidirectional call, Genesys documents that period as 5 minutes.

So, if both parties remain connected and RTP packets are still flowing - even if those packets contain silence - I would not expect Disconnect on Idle RTP to trigger at all.

That would lead me to investigate the situation in two different ways:

Scenario 1 – Both customer and agent are still genuinely connected

If neither side actually disconnected and they simply stopped talking, the SIP dialog and RTP session may be perfectly healthy.

In that case, this seems less like a trunk/carrier issue and more like a requirement for real-time conversational silence detection after the call has already been connected to an ACD agent.

Architect's Detect Silence action can help while the call is still being controlled by a flow, but after the ACD transfer and agent connection, I am not aware of a native Architect mechanism that continues monitoring the live conversation and disconnects it after X seconds of conversational silence.

Scenario 2 – The customer actually hung up earlier, but Genesys kept the call connected

This is where I would start looking at the telephony signaling.

For one of the affected conversations, I would try to correlate the Genesys conversation timeline with the carrier/SBC SIP trace and determine:

• At what exact timestamp did the customer actually disconnect?

• Was a SIP BYE generated by the carrier?

• When did that BYE reach Genesys Cloud?

• Did Genesys respond with the expected 200 OK?

• Did RTP continue to arrive after the customer supposedly disconnected?

• Was the SIP dialog being kept alive somewhere between the carrier/SBC and Genesys?

For example:

Customer hangs up → Carrier/SBC sends BYE → Genesys receives BYE → call disconnects

If the customer hangs up but no BYE reaches Genesys for another three minutes, I would investigate the carrier/SBC side.

If the BYE reaches Genesys immediately but the Genesys conversation remains connected, then I would open a case with Genesys Support using that SIP timeline as evidence.

There is also a third useful case to validate:

RTP actually stops, but no SIP BYE is received.

In that situation, Disconnect on Idle RTP should eventually provide protection, but according to the documented behavior, that would normally be after 5 minutes, which may explain why it does not address the 1–4 minute examples you are seeing.

Your participant disconnect reasons:

External = Endpoint
Internal = Peer

also seem consistent with the external participant ultimately being the side that terminates the interaction. But by themselves, those values probably do not tell us whether the customer attempted to disconnect several minutes earlier and the signaling was delayed somewhere upstream.

So I think the most important question is:

Can you confirm whether the customer is actually still connected during those silent minutes, or whether they have already hung up and the call remains established in Genesys?

If you have one affected conversation where you can compare the Genesys timestamps with the carrier/SBC SIP trace, that would probably tell us very quickly which scenario you are dealing with.

Hey Phaneendra,

I thought that this sounded familiar so I looked at what we had in the Product Ideas Lab. Unfortunately the closest idea that I could find was Play beep as reminder to agent when a call is on HOLD, It is listed as Under Consideration. I did not see any ideas for an audible reminder to agents that they are currently on a call so you may want to submit that idea.

As for the disconnect on silence, it should happen after a maximum of 1 minute of silence if you are running an outbound campaign. I don't believe there are any API calls that you can make in real time to monitor the health of the RTP stream on a call. Are you seeing that there is 1-4 minutes of dead air between the agent and the customer often?

Thanks, this is helpful. We're not seeing this across all calls - it appears to be specific to one particular call scenario, while other calls disconnect normally.

In the affected examples, there can be around 1–4 minutes of silence after the conversation has effectively finished, before the customer eventually disconnects. We've confirmed the participant disconnect pattern is External = Endpoint / Internal = Peer.

I agree the Detect Silence action doesn't appear to help once the interaction is already connected to an ACD agent. I'll also have a look at raising an Idea for an agent reminder/notification when a call remains connected after prolonged silence, as that may be a safer option than automatically disconnecting the interaction.

Hey Phaneendra,

I thought that this sounded familiar so I looked at what we had in the Product Ideas Lab. Unfortunately the closest idea that I could find was Play beep as reminder to agent when a call is on HOLD, It is listed as Under Consideration. I did not see any ideas for an audible reminder to agents that they are currently on a call so you may want to submit that idea.

As for the disconnect on silence, it should happen after a maximum of 1 minute of silence if you are running an outbound campaign. I don't believe there are any API calls that you can make in real time to monitor the health of the RTP stream on a call. Are you seeing that there is 1-4 minutes of dead air between the agent and the customer often?

HI Phaneendra,

Another point I would like to add for our investigation is that we need to check the following two scenarios:

1. No RTP / Media Inactivity

In this scenario, RTP packets stop arriving for a configured duration. If no RTP is received within the configured period, the call may be terminated, typically by sending a SIP BYE.

For this case, we should verify which party sent the BYE. If the BYE was received from the external customer end, we should also check the SIP Reason header, if available, to understand the reason for the call termination.

BYE sip:+971501234567@10.10.10.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bKabc123
From: <sip:+971500000001@10.10.10.10>;tag=123456
To: <sip:+971501234567@10.10.10.20>;tag=654321
Call-ID: 8a7f3c2d4e5f@10.10.10.10
CSeq: 2 BYE
Reason: SIP ;cause=408 ;text="RTP Timeout"
Content-Length: 0

2. Silence Detection

This is different from RTP inactivity. RTP packets may still be flowing normally, but the audio payload may contain only silence.

For example:

In this scenario, the RTP stream may appear healthy from a transport perspective, so we may need to analyze the RTP/audio stream to determine whether there was actual silence or no speech for a specific duration

For example, in Wireshark:

Telephony
   → RTP
      → RTP Streams
         → Analyze
         → Play Streams

Thank You

Thanks, this is helpful. We're not seeing this across all calls - it appears to be specific to one particular call scenario, while other calls disconnect normally.

In the affected examples, there can be around 1–4 minutes of silence after the conversation has effectively finished, before the customer eventually disconnects. We've confirmed the participant disconnect pattern is External = Endpoint / Internal = Peer.

I agree the Detect Silence action doesn't appear to help once the interaction is already connected to an ACD agent. I'll also have a look at raising an Idea for an agent reminder/notification when a call remains connected after prolonged silence, as that may be a safer option than automatically disconnecting the interaction.

Hey Phaneendra,

I thought that this sounded familiar so I looked at what we had in the Product Ideas Lab. Unfortunately the closest idea that I could find was Play beep as reminder to agent when a call is on HOLD, It is listed as Under Consideration. I did not see any ideas for an audible reminder to agents that they are currently on a call so you may want to submit that idea.

As for the disconnect on silence, it should happen after a maximum of 1 minute of silence if you are running an outbound campaign. I don't believe there are any API calls that you can make in real time to monitor the health of the RTP stream on a call. Are you seeing that there is 1-4 minutes of dead air between the agent and the customer often?

Thanks everyone for the suggestions and input.

I investigated a couple of the affected interactions and confirmed that both parties remained connected during the additional 1–4 minutes.

The customer eventually disconnected, and the agent leg cleared almost immediately afterwards - 4 ms in one example and 7 ms in another. The participant disconnect reasons (External = Endpoint / Internal = Peer) also indicate that the customer initiated the final disconnect.

So this wasn't a case of the customer hanging up and Genesys leaving the agent connected for several minutes.

I also reviewed several other interactions and haven't seen the same behaviour more broadly. So far, it appears to be isolated to one particular agent, which suggests this is more likely an agent behaviour/process issue rather than a general Genesys or telephony issue.

My original question was whether we could detect prolonged conversational silence towards the end of an active agent call for example, the conversation has finished/customer has said goodbye, but neither side disconnects and then notify the agent or automatically disconnect after a threshold.

Based on the discussion, it doesn't appear there is currently a native way to monitor this type of conversational silence once the call is connected to an ACD agent. Disconnect on Idle RTP is already enabled in our environment, but that addresses missing RTP rather than conversational silence.

Thanks again everyone, this was really helpful in narrowing down what was actually happening.

Hi Phaneendra,

Thanks for sharing the results - I think this really clarifies what was happening.

The 4 ms / 7 ms clearance of the agent leg after the customer finally disconnected, together with External = Endpoint / Internal = Peer, seems to rule out the telephony/SIP signaling scenario we were initially considering. Both legs were genuinely still connected during those additional minutes.

I also think the distinction Narasimha raised between RTP inactivity and conversational silence is the key point here. Disconnect on Idle RTP only helps when RTP itself stops arriving; if RTP continues while neither party is speaking, the call is still healthy from a media/session perspective.

One interesting detail is that Genesys does already calculate Silence as an acoustic metric in Speech and Text Analytics - including periods where neither the customer nor the agent speaks - but that appears to be an analytics capability rather than a real-time control that can warn the agent or disconnect an active ACD call after a silence threshold.

So I agree with your conclusion regarding the native functionality.

If this became an important operational requirement, one possible direction might be AudioHook Monitor, since Genesys can stream the conversation audio in near real time to an external service. A custom service could theoretically detect prolonged conversational silence and trigger some downstream action. Of course, that would be a custom architecture rather than a native queue/telephony setting.

This was a very interesting case - and the comparison of the actual disconnect timing made the root cause much clearer.

------------------------------
Fernando Sotto dos Santos
Consultor de Atendimento Senior Grupo Casas Bahia
------------------------------


Original Message:
Sent: 08-21-2026 03:15
From: Phaneendra Avatapalli
Subject: Automatically disconnect an active ACD call after prolonged silence?

Thanks everyone for the suggestions and input.

I investigated a couple of the affected interactions and confirmed that both parties remained connected during the additional 1–4 minutes.

The customer eventually disconnected, and the agent leg cleared almost immediately afterwards - 4 ms in one example and 7 ms in another. The participant disconnect reasons (External = Endpoint / Internal = Peer) also indicate that the customer initiated the final disconnect.

So this wasn't a case of the customer hanging up and Genesys leaving the agent connected for several minutes.

I also reviewed several other interactions and haven't seen the same behaviour more broadly. So far, it appears to be isolated to one particular agent, which suggests this is more likely an agent behaviour/process issue rather than a general Genesys or telephony issue.

My original question was whether we could detect prolonged conversational silence towards the end of an active agent call for example, the conversation has finished/customer has said goodbye, but neither side disconnects and then notify the agent or automatically disconnect after a threshold.

Based on the discussion, it doesn't appear there is currently a native way to monitor this type of conversational silence once the call is connected to an ACD agent. Disconnect on Idle RTP is already enabled in our environment, but that addresses missing RTP rather than conversational silence.

Thanks again everyone, this was really helpful in narrowing down what was actually happening.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------