### Answer This is likely related to end-to-end latency, which measures the total time from when a person stops speaking until the agent begins responding — this includes processing time, network delays, and model inference time [(1) ]() . Some overlap/talking-over can happen if this latency is high enough that the system doesn't register the person has started speaking again before the agent responds. To investigate this for the affected calls, you can check per-call latency breakdowns in Call History or via the Get Call API . The API response includes a

latency

object with per-component metrics:

curl -X GET "<https://api.retellai.com/v2/get-call/CALL_ID%22> \
 -H "Authorization: Bearer YOUR_API_KEY"

This breakdown includes fields such as: - **e2e**: end-to-end latency from when the user stops talking to when the agent starts talking (only counts turns where the agent speaks) - **asr**: transcription latency - **llm**: LLM latency from the start of the LLM call to the first speakable chunk - **tts**: text-to-speech latency from triggering TTS to the first audio byte - **knowledge_base**: knowledge base retrieval latency, only populated if the agent uses that feature Checking these values for the specific transferred calls would show whether the delay is coming from ASR, LLM, TTS, or knowledge base retrieval, rather than assuming it's simply something to "adjust to." Separately, if this delay is specifically happening during the transfer itself (not general conversation turns) , it's worth checking your call transfer node configuration — for example, whether human detection or auto-greet settings on a warm transfer are adding wait time before the agent responds [(2) ]() . If you want to dig into troubleshooting steps for reducing high latency once you've identified which component is slow, let me know and I can point you to the relevant guidance.

​ To learn more, see the sources I considered: [[1] Check actual latency](https://docs.retellai.com/reliability/check-actual-latency) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Once a warm transfer connects the destination to your caller, the AI agent drops off the call entirely — at that point, Retell's agent is no longer part of the audio path [(1) ]() . This means any speech overlap or delay happening after the human agent picks up isn't coming from Retell's AI processing (ASR, LLM, TTS) anymore, since that pipeline is only active while the agent is still on the line. Given you're using RingCentral for the phone number, the delay your client is describing is most likely on the telephony/SIP signaling side rather than Retell's AI stack. Retell's SIP server architecture handles call setup, routing, and voice processing (STT/TTS) only while the AI agent is engaged in the call, and once transferred, downstream call quality and connection timing depend on the telephony provider (in this case, RingCentral) and its SIP trunk configuration [(2) ]() . A few things worth checking: - Whether the delay happens specifically during the handoff moment (agent-to-human bridging) — this would point to telephony-side call setup/signaling latency rather than Retell's e2e latency metric, since that metric only measures turns where the Retell agent speaks [(1) ]() . - Your SIP trunk setup and authentication with RingCentral, since termination/origination URI configuration and provider-side call routing affect how quickly the bridged call connects [(2) ]() . - The transfer type in use — cold transfer connects the caller directly to the destination and the agent drops immediately, while warm transfer has the agent wait on the line until a person picks up

before bridging; the wait behavior itself is configurable via "Wait Time for Agent Answer" and "Internal queue or hold system" settings [(1) ]() . There's also a related community forum thread describing very similar symptoms — callers hearing hold music or delays around the transfer moment, and reports that the issue was added to Retell's roadmap rather than resolved short-term [(3) ]() . Note that forum content isn't official documentation, so treat it as anecdotal context rather than a confirmed root cause. If you want to pin down whether it's Retell-side, checking whether the delay occurs before or after the "agent drops off" point in the call recording/transcript would help isolate it — anything after that point is outside Retell's AI processing and would point to RingCentral's call handling.

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] AI in SIP Calling & Telephony Solutions | Retell AI](https://www.retellai.com/blog/integrating-ai-with-sip-trunking-and-modern-telephony) [[3] Warm Transfers](https://discord.com/channels/1186424376300679209/1289365041010835518) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

Thanks for the follow-up, @Alexander. I'll get back to you soon.

### Answer Once a warm transfer bridges the caller to the human, Retell's AI agent drops off the call completely and is no longer part of the audio path [(1) ]() . So any speaking-over-each-other delay happening after that handoff point is not coming from Retell's AI processing (ASR/LLM/TTS) — it's on the telephony/SIP side, which in this case is RingCentral [(2) ]() . To confirm: check whether the delay occurs before or after the agent-drop-off point in the call transcript/recording. Anything after that point points to RingCentral's call handling, not Retell [(1) ]() [(2) ]() .

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer That explanation is partially correct but mixes up a detail. Here's the accurate breakdown: Your colleague is right that once a warm transfer bridges the caller to the destination, the AI agent drops off and the caller and destination remain connected directly [(1) ]() . That part matches the documentation. However, the SIP method detail isn't quite right. SIP INVITE vs. SIP REFER is a setting specific to cold transfer, not warm transfer — it's described as "the SIP method used to hand off the call" for cold transfers, with options being SIP INVITE (the default) or SIP REFER . Warm transfer instead uses SIP DIAL when setting caller ID to the user's number, dialing out the

from

and

P-Asserted-Identity

headers . So to correct the statement: for warm transfers, once the agent bridges the call and drops off, the caller and destination stay connected directly — that's accurate. But this isn't because of "SIP Invite" specifically; SIP INVITE is a cold-transfer-specific setting, and warm transfer's caller ID mechanism uses SIP DIAL . This doesn't fully explain the delay itself, though — nothing in the sources describes post-bridge audio latency being caused by the transfer's SIP method. Once bridged, that portion of the call is a direct telephony connection outside Retell's AI processing , so any lag there would point to the telephony leg (RingCentral, in your case) rather than a Retell-specific mechanism.

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Based on the information sources available to me, I can confirm the core point in your team member's message: once a warm transfer bridges the call, the AI agent drops off, and the caller stays connected directly to the destination [(1) ]() . On the SIP detail: the sources here don't contain the "Transfer call tool (single & multi-prompt agents) " documentation referenced in earlier replies. What I do have access to is the conversation flow version of the call transfer node . From that source: - For cold transfer, the SIP method (SIP INVITE or SIP REFER) is configurable, and caller ID override depends on which mode is used . - For warm transfer, caller ID override to show the user's number uses SIP DIAL, setting the

from

and

P-Asserted-Identity

headers . - Once a human is detected and the caller is connected, the agent's job is done for that call segment — the whisper/three-way message settings only apply before the bridge . Nothing in the sources describes what causes audio delay or overlap after the bridge completes. Since the agent is no longer part of the audio path once the transfer completes, the direct telephony connection between caller and destination is outside Retell's processing. For the actual question — is this a RingCentral issue — that determination isn't something the sources can confirm one way or the other, since they don't cover RingCentral-specific behavior. My suggestion: before telling the client "yes, it's on RingCentral," verify by checking exactly where in the call timeline (before or after the transfer bridges) the overlap happens. If it's after the bridge, that's consistent with it being outside Retell's AI processing, but confirming it's specifically a RingCentral-side issue would need to come from your telephony logs, not from what's docume

nted here.

​ To learn more, see the sources I considered: [[1] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer That client-side explanation is broadly consistent with what's documented on the Retell side: during a warm transfer, the call goes through a hold/bridging process where SIP signaling and processing happens before the human agent is connected — this involves human detection, optional whisper messages, and a three-way introduction before the caller is bridged [(1) ]() . This bridging process does involve SIP handling across the transfer, so it's reasonable that some processing time occurs during that handoff. However, I can't confirm the specific claim about "media path travels from RC to AI, and possibly live agents" as a factual routing description — that level of detail about RingCentral's specific media path isn't something in the sources I have access to. The sources only describe Retell's side of the transfer mechanics: once the caller is bridged to the destination, the agent's job (whisper message, three-way message) is complete for that segment . Bottom line: I can't confirm or deny the RingCentral team's specific technical explanation of "media path" routing, since that's outside what's documented in my sources. What I can confirm is that warm transfers do involve a bridging/hold period with SIP processing before the caller connects, which aligns with their general point that delay during multi-platform handoffs is plausible . I wouldn't push back on their explanation, but I also can't independently verify the specific mechanics they described.

​ To learn more, see the sources I considered: [[1] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer A few adjustable settings on the warm transfer side that could shorten the pre-bridge delay: - **Agent detection timeout**: the max time the AI waits to confirm a human answered before connecting the caller — default is 30 seconds. If human detection is taking close to this, lowering it could reduce wait time, though it risks connecting before a human is actually confirmed [(1) ]() . - **Auto-greet**: enabling this makes the agent immediately say "Hello" when the destination picks up, which encourages a faster response and can speed up human detection . - **Transfer ring duration**: this only controls how long the destination rings, not the bridging delay itself, but worth checking it isn't set unnecessarily high . None of these settings target delay after the bridge completes — once the caller is connected to the destination, the agent has dropped off and that portion of the call is a direct telephony connection outside Retell's processing . So if the overlap your client described happens after the human picks up and starts talking, there's nothing on the Retell/warm-transfer configuration side that would address it — that would fall to the telephony leg (RingCentral, per your context) . To narrow this down, I'd check the call transcript/recording for where exactly the delay occurs relative to the bridge point. If it's during the human-detection/whisper phase, tuning the settings above could help. If it's after the bridge, that's outside what Retell's transfer configuration can control.

​ To learn more, see the sources I considered: [[1] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[2] Connect Retell voice agents to custom telephony](https://docs.retellai.com/deploy/custom-telephony) ​

### Answer Once the caller is bridged to the destination and the AI agent drops off, that call segment becomes a direct telephony connection outside Retell's processing [(1) ]() . None of the sources describe controls for reducing latency that occurs after the bridge completes — the configurable settings for call transfer nodes (agent detection timeout, auto-greet, on-hold music, whisper/three-way messages, transfer ring duration, caller ID mode, SIP INVITE vs. SIP REFER for cold transfer) all apply to the pre-bridge phase, not to audio quality once the human and caller are talking directly . So based on what's documented, there isn't a Retell-side setting to fix delay happening after the human is already on the line with the patient. That would need to be investigated on the telephony/SIP leg (RingCentral, in your case) , since Retell's AI agent is no longer part of the audio path at that point . If you want, I can point you to where to check call-level SIP/telephony configuration docs for custom telephony providers, but the sources here don't describe a fix that lives on the Retell side for post-bridge audio delay [(2) ]() .

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.