We are using RetellAI’s default telephony provider (no custom SIP integration).
Our use case involves inbound PSTN calls being transferred to a Retell AI Voice Agent. During this transfer flow, we are encountering two issues:
Call drops during or shortly after transfer
Some calls disconnect either during the transfer process or within a few seconds after the agent answers. The issue is intermittent but frequent enough to impact production stability.
Duplicate call records for a single transfer
In certain cases, two separate call records are generated for what appears to be a single transferred call. This is creating complications in downstream tracking and request handling.
We would like clarification on the following:
For accounts using Retell’s default telephony, are detailed SIP-level traces (such as INVITE, provisional responses, ACK, BYE, and timestamps) available for debugging?
If so, where can these logs be accessed?
Is duplicate call creation expected behavior during certain transfer scenarios (for example, re-INVITE, REFER, or internal re-origination flows)?
Are there any known considerations or best practices for handling inbound transfer scenarios to avoid call drops?
Any guidance on how to approach debugging this transfer flow would be appreciated.
For debugging call transfer issues with Retell’s default telephony, you can access SIP connection logs in the call logs.(1) These logs are useful for diagnosing transfer failure reasons.(1)
Accessing Detailed Logs
The SIP connection log is available in the call logs and is useful for diagnosing the failure reason.(1) You should check the call history and detailed log, which contains the disconnection reason, the SIP error code, and the error message.(2) In most cases, this provides enough information to identify the root cause.(2)
Transfer-Specific Troubleshooting
When call transfer is not triggered or fails, verify your transfer_call function implementation.(1) Check your agent configuration to confirm that you’ve added the transfer_call function to your agent’s function list.(1) Review transfer conditions and ensure the transfer_call function description is specific and unambiguous.(1)
Common Transfer Failure Scenarios
If call transfer is triggered but failed, there are several possible causes:(1)
Telephony issues: Call transfer is similar to placing an outbound call, and failures occur for similar reasons as outbound call failures.(1)
Could not detect human: If human detection is enabled, the call may fail if a human is not successfully detected.(1) Possible reasons include no human being actually present (e.g., it was an IVR or voicemail), the other party speaking only after the detection timeout expired, or the speech being too similar to an IVR or voicemail and not recognized as human.(1)
Duplicate Call Records
Based on community discussions, duplicate call entries can occur in certain scenarios.(3) One community member noted: “Some provider like Twilio can call the webhook multiple times for a single call. In those cases, you will need to dedupe the call.”(3) While this specifically references custom telephony setups, similar webhook behavior may apply to default telephony.
Recommended Next Steps
Check call detailed logs for specific SIP error codes and disconnection reasons(2)
Verify your transfer_call function configuration(1)
Review transfer node settings if using conversation flow agents(1)
Test with sample scenarios to validate transfer triggers(1)
For additional support with this production issue, you can:
I would like to clarify that our issue is not related to agent-initiated transfers using the transfer_call function.
The instability occurs specifically in the following flow:
An end user calls our primary PSTN number.
That call is carrier-transferred to a Retell AI agent phone number (using Retell’s default telephony provider).
The call either drops during the transfer handshake or connects briefly and disconnects within a few seconds.
This issue does not occur when a Retell agent transfers calls outbound. It is specific to inbound PSTN calls being transferred to Retell.
Additionally, in some cases, two separate call records are generated for what operationally appears to be a single transferred session. This is creating complications in downstream tracking and request correlation.
We reviewed the SIP connection logs available in the dashboard. However, they only provide high-level disconnect reasons and summarized SIP error codes.
For proper telecom-level debugging, we require visibility into:
Without full signaling traces (ladder view or pcap-level logs), we cannot determine whether the root cause is:
Premature BYE from the upstream carrier
REFER handling issue
Missing ACK
SDP or codec negotiation failure
RTP timeout
Session-Expires mismatch
Internal re-origination of call legs
We would appreciate clarification on the following:
For accounts using Retell’s default telephony provider, is it possible to access raw SIP traces (pcap or ladder format) for specific call IDs?
If these are not available in the dashboard:
Can they be requested from support for specific timestamps?
Is there an advanced logging option that enables deeper SIP-level visibility?
Regarding duplicate call records:
Does Retell internally create a new call leg when handling inbound carrier transfers (e.g., REFER)?
Is this expected behavior for blind transfer scenarios?
How should multiple call IDs belonging to a single transferred session be correlated?
This issue is impacting production reliability, and detailed SIP-level visibility is essential for isolating the failure domain between upstream carrier signaling and Retell’s session handling.