We are currently using custom Twilio integration with SIP trunks to handle inbound calls only. All phone numbers are connecting successfully, and the AI agent is functioning correctly during conversations.
However, we are facing an issue with dynamic cold call transfers. When the agent attempts to transfer a call, the tool call fails with the following response:
{
"status": "Transfer call cannot be completed, probably don't have the permission to perform the transfer.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly."
}
This feature was previously working perfectly, and no intentional changes have been made on our end. The issue is now occurring consistently across all numbers and agents.
Transfer Tool Configuration
{
"type": "transfer_call",
"name": "transfer_call_to_phone_number",
"speak_during_execution": true,
"execution_message_description": "Sure! I am transferring your call right now",
"execution_message_type": "prompt",
"transfer_destination": {
"type": "inferred",
"prompt": "If the user wants to reach support, transfer to +15*********"
},
"transfer_option": {
"type": "cold_transfer",
"show_transferee_as_caller": false,
"cold_transfer_mode": "sip_invite",
"agent_detection_timeout_ms": 30000
},
"custom_sip_headers": {},
"ignore_e164_validation": false
}
Key Questions
Why are transfer tool calls now failing with a permission-related error?
Has there been any recent change in Retell’s permissions, SIP transfer handling, or Twilio-related configurations?
Are there specific account-level permissions or flags required for sip_invite cold transfers?
What logs or diagnostics can we use to further debug this issue?
We can provide full payloads, call logs, and timestamps if needed.
This issue is currently blocking our call transfer workflow, so any guidance would be greatly appreciated.
The key finding is that these transfers are not failing due to a Retell permission issue — the failures are occurring at your Twilio trunk layer. Here’s the breakdown:
What the logs show for each call:
call_553 and call_658: Your Twilio trunk returned SIP 486 “Busy Here” when attempting to reach +923364135xxx. The tool correctly reported “the other side is busy.”
call_9232 and call_b5d: Your Twilio trunk timed out — the Pakistan number rang but didn’t answer within 30 seconds. The tool reported “the other side did not pick up.”
The transfer routing is correct: team verified via PCAP analysis that the outbound INVITE goes to your own Twilio trunk staging-voice-omerbhatti34.pstn.twilio.com) with proper authentication — not through Retell’s default infrastructure. No Retell-side permission or configuration issue is involved.
Recommended next steps on the Twilio side:
Check Twilio Geo Permissions: In your Twilio console, navigate to Voice → Settings → Geo Permissions and confirm Pakistan (+92) is enabled for outbound dialing. A common Twilio behavior is returning 486 “Busy Here” for geo-restricted destinations instead of a clear 403 Forbidden.
Verify account type: If staging-voice-omerbhatti34 is a trial or staging Twilio account, international calling may be restricted.
Check Twilio call logs: Look for the transfer attempts in your Twilio dashboard to see the exact reason for the 486 response.
Test directly: Try calling +923364135xxx directly from your Twilio account (outside of Retell) to confirm the number is reachable through your Twilio setup.
There have been no recent Retell changes to the cold transfer or SIP trunk routing code that would affect your setup.
We’ve configured Twilio with a referUrl endpoint to handle call transfers. However, during transfer attempts, we do not see any SIP REFER being sent from your side. Instead, the call is terminated with a BYE.
We have historical logs from Feb 25 showing Twilio successfully received SIP REFER and triggered our /refer webhook with ReferTransferTarget=<tel:+15174428672>. In the latest failing calls, we reviewed multiple SIP traces and no REFER is present; the call ends with BYE instead. This indicates the transfer behavior changed before Twilio reaches our referUrl.
we weren’t mentioning the sip_transfer method specifically and relying on retell’s default value. we just hardcoded this value in sdk and it’s transferring perfectly fine