https://retellai.com/?utm_source=discord&utm_medium=seo logo
Powered by
Transfer looping back into the same agent when the...
# ❓・ai-evy-support
b
@AI Evy Transfer looping back into the same agent when the destination has conditional call forwarding Setup: a clinic with a single main line. The carrier (Spectrum) forwards on no answer after 3 rings to our Retell number, so the agent picks up whatever the front desk misses. The agent also uses transfer_call (warm transfer with whisper) to hand callers back to that same main line when they ask for a person. The edge case: the agent transfers to the main line, nobody at the desk picks up within 3 rings, and the carrier forwards that leg right back to our Retell number. The transfer technically connects, but it connects to a new inbound call on the same agent, so the caller just hears the greeting again. Because nothing failed, our "if the transfer does not connect" fallback never fires. Questions: Does Retell detect a transfer that lands back on one of our own numbers, or is there any loop protection for this? Is the ring timeout on transfer_call configurable? We'd like the transfer to time out before the carrier forward kicks in (roughly 15s instead of 30s), so the failure path runs instead. What's the parameter and the default? On a warm transfer, does the whisper wait for a human to answer? We currently have human detection opted out. Would enabling it catch an AI agent answering on the other end? Is there a recommended pattern for single-line businesses where the transfer destination is the same number that forwards into the agent?
a
Thanks for tagging me @B11TENCOURT. I'll look through relevant sources and get back to you shortly.
​ 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] Transfer call tool for single & multi-prompt agents](https://docs.retellai.com/build/single-multi-prompt/transfer-call) ​
### Answer --- Ring timeout is configurable. You can set a custom transfer dial timeout using a slider in the call transfer configuration [(1) ]() . This timeout value applies only to that specific transfer . If you don't set it, Retell uses your agent-level ring duration setting . This works for cold transfer, warm transfer, and agentic warm transfer [(1) ]() [(2) ]() . Human detection and whisper messages. When you enable human detection on a warm transfer, the agent checks if a human is present after the transfer target answers, and the original caller is only connected once a human is detected . The whisper message is spoken privately to the transfer target before connecting them to the original caller . With human detection enabled, you can configure an agent detection timeout—the maximum time the AI agent will wait to determine whether the transfer target is a human . The caller is connected only if human detection succeeds within this timeframe; otherwise, the transfer is marked as failed . The default timeout is 30 seconds . Auto-greet feature. If enabled, the agent will immediately say "Hello" when the transfer target picks up, which encourages a response and increases the likelihood of detecting a human . No explicit loop detection mentioned. The available sources do not mention built-in loop protection for transfers that land back on your own Retell numbers. Recommended approach for your scenario: Set the transfer dial timeout to 15 seconds (before your carrier's 3-ring forward kicks in) [(1) ]() . Enable human detection with a reasonable agent detection timeout [(
1) ]() [(2) ]() . This combination should cause the transfer to fail and trigger your fallback logic before the carrier forward creates the loop.
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
b
Thanks @AI Evy that's helpful. A few follow-ups on the same setup: Can human detection tell an AI voice agent apart from a human? In our loop scenario the call is answered by another Retell agent, which greets the caller normally. Does human detection classify that as human and connect, or is there any signal that flags an AI on the other end? Same question with auto-greet enabled, since the "Hello" would just make the other agent respond. Do we get the forwarding metadata on an inbound call? When a carrier forwards a call to our Retell number, the invite usually carries a SIP Diversion or History-Info header with the number that diverted it. Is that exposed anywhere we can read (dynamic variables, call metadata, the webhook payload)? If we could see that a call was diverted from our own transfer destination, the agent could recognize the loop and end the call instead of greeting the patient again. What does the original caller hear while a warm transfer is dialing, and after it times out? We're setting a 15 second dial timeout. Does the caller stay on hold music for those 15 seconds and then come back to the agent cleanly, or is there a noticeable gap or any risk of the call dropping? Which event fires when a transfer times out? We subscribe to transfer_started, transfer_bridged and transfer_cancelled. Is a dial timeout reported as transfer_cancelled, and does the payload say why it failed? We want to log failed transfers in our first week of live traffic.
a
Thanks for the follow-up, @B11TENCOURT. I'll get back to you soon.
​ To learn more, see the sources I considered: [[1] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Webhook Overview](https://docs.retellai.com/features/webhook-overview) ​
### Answer Forwarding metadata is available via custom SIP headers. When a carrier forwards a call to your Retell number, custom SIP headers extracted from the inbound INVITE are provided in the 
custom_sip_headers
object [(1) ]() . Only headers whose name starts with 
X-
(case-insensitive) , plus the allowlisted headers 
User-to-User
, 
Diversion
, 
History-Info
, and 
P-Asserted-Identity
, are forwarded . Header names are emitted in lowercase . The object may be empty or omitted when no qualifying headers are present, so treat it as optional . You can access these headers in your inbound webhook payload to detect when a call was diverted from your own transfer destination . On-hold music during warm transfer. For warm transfers, you can configure the on-hold music that plays to the caller while they are on hold [(2) ]() . The default is a standard ringtone . The caller hears this configured audio while the transfer is dialing . Transfer timeout events. When you subscribe to transfer webhooks, 
transfer_cancelled
is triggered when a transfer is cancelled or fails to connect [(3) ]() . The webhook payload includes 
transfer_destination
and (when available) 
transfer_option
. For transfer events, use 
event
+ 
call_id
+ 
start_timestamp
(and, if needed, 
transfer_destination
) to ensure each transfer attempt is processed exactly once, since a single call may contain multiple transfer attempts . Human detection limitations. The documentation states that when human detection is enabled, the agent checks if a human is present after the transfer target answers [(2) ]() . However, the sources don't explici
tly address whether human detection can distinguish an AI voice agent from a human speaker. The system is designed to detect human presence, but there's no documented signal that specifically flags an AI agent on the other end . **
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
b
Do you support a blocklist of inbound numbers, per phone number or per agent? If we could simply block our own Retell numbers from calling in, we wouldn't need to handle this in a webhook at all. @AI Evy
a
Thanks for the follow-up, @B11TENCOURT. I'll get back to you soon.
​ To learn more, see the sources I considered: [[1] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) ​
### Answer You can block specific inbound numbers using the inbound webhook [(1) ]() . Set up an inbound webhook and return 
reject: true
in your response to decline calls from specific numbers . The webhook receives the 
from_number
in the request payload, which you can check against your blocklist . When you respond with 
reject: true
, Retell hangs up before any agent or voice setup, and no call object is created . Here's how the webhook works: the request includes 
from_number
and 
to_number
. You check the 
from_number
against your list of blocked numbers (including your own Retell numbers) , then respond with:
Copy code
json
{
  "call_inbound": {
    "reject": true
  }
}
Only the boolean 
true
rejects the call—any other value is ignored and the call proceeds normally . Rejecting takes priority over agent selection, so 
override_agent_id
and 
agent_override
are ignored when 
reject
is 
true
. This approach lets you block your own Retell numbers from calling in without needing per-agent or per-number blocklist configuration .
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
PreviousNext
Powered by