We have started experiencing a persistent, repeatable issue with our transfer_call function. Our test bot has only one thing to do: transfer the user to Zendesk once the user says transfer to a human agent. The bot is only created for testing purposes of transferring.
The transfer is failing immediately after the agent calls the function, and the error indicates a platform issue(as there is no response code to the external provider), not an issue with our configuration (it used to work before).
Please investigate the following Call ID, as the error is clearly visible in the detailed logs:
Failed Call ID (Latest Attempt):call_784b752bfb3f2dc0aae7fd120ee
Success Call ID:call_b6144b52a742dd4d31ff515ef7. It used to work on 15.12.2025
Log from call history logs: 2025-12-29 13:51:31.514 call_784b752bfb3f2dc0aae7fd120ee error: Error transferring: Error: Call country not supported: undefined, sip: our_domain_name.sip.twilio.com at validatePhoneCall (file:///usr/src/app/dist/api/phone_number_util.js:548:19) at OrchestratorWebRTC.transferCallFunction (file:///usr/src/app/dist/webrtc/orchestrator_webrtc.js:1499:23)
Target Transfer Number: The destination number is correctly formatted as E.164
Issue: The LLM successfully recognized the intent and executed the transfer_call tool, but the transfer doesn’t work.
Additional information: The Number from which I make a call is +48 (Poland), the number to which I make a call is bought in Retell, and it’s a US number (+1).
We have already verified that the destination number is active and that the agent’s number is correctly provisioned.
We require assistance with the Call country not supported error being returned, and what is more confusing, why it was working on and before the 15th of December without any issues
Based on the error message “Call country not supported: undefined” in your logs, this appears to be a telephony provider configuration issue rather than a problem with your transfer_call function setup(1).
Key troubleshooting steps:
For call transfer issues in single/multi-prompt agents, verify that the transfer_call function is properly added to your agent’s function list(1). The transfer destination should be set to either a number in E.164 format or a SIP URI in the format sip:username@domain(2).
Call transfer is only supported for phone calls, not web calls(2). Since you’re using a Retell-purchased US number (+1) and calling from Poland (+48), verify that your Retell number supports international transfers.
Common transfer failure causes:
Telephony issues are similar to outbound call failures - the SIP connection log available in your call logs can help diagnose the failure reason(1). When transfers fail, possible reasons include:
No human was actually present (e.g., it was an IVR or voicemail)(1)
The other party spoke only after the detection timeout expired(1)
The speech was too similar to an IVR or voicemail and wasn’t recognized as human(1)
Configuration to verify:
Ensure your transfer number extension is correctly set if needed - extensions must be 0-9, ‘*’, ‘#’ (e.g., 123#)(2). If using custom telephony and your transfer destination is not in E.164 format, you can choose to keep the input as is by selecting raw format(2).
Given that this worked previously on December 15, 2025, and the error mentions “Call country not supported: undefined,” I recommend:
Hello @Aleksander_Wojcik ,
I can’t find any call with this id: call_b6144b52a742dd4d31ff515ef7
Can you try the transfer with the display number as the retell number instead of the user’s number, and also, can you use the number instead of the SIP URI?
To help troubleshoot the call ID issue and transfer configuration, here are a few steps:
Verifying the Call ID
The call ID format you mentioned (call_b6144b52a742dd4d31ff515ef7) appears to follow Retell AI’s call ID format(1). You can retrieve call details using the List Calls API endpoint(2). The call_id field is used to identify calls in the system(1)(3)(2)(4).
Transfer Configuration Recommendations
Based on the available documentation:
Display Number Options: When configuring transfers, you have options for which number displays to the transfer recipient(5). The documentation indicates there are known limitations with certain telephony providers when using “Transferee’s Number” as the displayed caller ID(5).
Using Phone Numbers vs SIP URIs: The transfer_destination field can accept both phone numbers (in E.164 format like “+12137771234”) and SIP URIs (prefixed with “sip:”)(1)(3)(2). However, using a standard phone number format may provide more reliable results depending on your telephony provider configuration(5).
Retell Number as Caller ID: Using your Retell/Twilio DID as the displayed number is often more reliable than attempting to pass through the original caller’s number, particularly with certain telephony providers(5).
To retrieve the specific call details and verify its status, you can use the List Calls API with the call ID as a filter(2).
@Omar_Ashraf It looks like it started working fine; it works with SIP and a number. The problem was with Zendesk. Is it possible to have more detailed logs than in Call history logs?
Great to hear the transfer is working now with both SIP and number formats(1).
Regarding more detailed logs than what’s available in Call History, you can access the public log for each call, which contains comprehensive details about all requests and responses received in the LLM WebSocket, latency tracking for each turn-taking, and is helpful for debugging and tracing(1). This public log becomes available after the call ends(1).
You can retrieve the public log URL through the List Calls API:
The Call History dashboard provides access to detailed logs by navigating to Call History, selecting the specific call, and clicking the “detail logs” tab(2). You can also customize which columns appear in the history table by clicking the “Customize Field” button in the top-right corner(3).
For programmatic access to call details including logs, you can use the List Calls API endpoint with filtering criteria(1):
import Retell from 'retell-sdk';
const client = new Retell({
apiKey: 'YOUR_RETELL_API_KEY',
});
const callResponses = await client.call.list();
console.log(callResponses);
The API response includes comprehensive call information such as transcript, recording URLs, latency metrics, disconnection reasons, and the public_log_url(1).
That’s great to hear! Since you’re using custom telephony, you should have a PCAP file from your provider that contains more detailed information about the call.