Twilio cold transfer not working

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.

Thank you.

Hi @m.hariss123

Could you please share your Call IDs were transfer not worked? This will help us investigate the issue more effectively.

Thank you!

Call Ids with failed transfer tool

call_553df9dc5d71654f980b637eb36
call_9232e2224518c96f8cf10cd3753
call_b5d04f6ef976bcfe6b22ed6dd87
call_658f898837768f6ee7327646f8b

and many more.

Hey @m.hariss123

Thanks for sharing the call IDs. I’ve forwarded them to our team for further investigation.

We’ll get back to you as soon as we have an update.

Best regards

Here is the call ID that did transferred the call successfully (just for reference)

call_5a896cbc5738bc4793ac16aa1cb

Hello @m.hariss123

Team investigated all 4 calls.

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:

  1. 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.
  2. Verify account type: If staging-voice-omerbhatti34 is a trial or staging Twilio account, international calling may be restricted.
  3. Check Twilio call logs: Look for the transfer attempts in your Twilio dashboard to see the exact reason for the 486 response.
  4. 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.

Thank You

Thanks i’ll go through all the steps and let you know what was thee reason.

After doing all 4 suggested checks and changes the transfer is still not working.
Please check this call ID

call_31b0c696b9ba2f994c366ffc7c0

This is the call log from twilio

We used to recieve a refer callback whenever a transfer was initiated. We don’t recieve it anymore.

this is our /refer endpoint.

        payload = dict(request.POST)
        refer_transfer_target = (payload.get("ReferTransferTarget") or [None])[0]
        dial_type, dial_target = self._normalize_refer_transfer_target(
            refer_transfer_target
        )

        voice_response = VoiceResponse()
        if dial_type and dial_target:
            dial = Dial()
            if dial_type == "sip":
                dial.sip(dial_target)
            else:
                dial.number(dial_target)
            voice_response.append(dial)

Hello @m.hariss123

I’ve escalated this again to our team for further review.

We’ll update you as soon as we hear back.

Best regards

Hey @m.hariss123

Can you send the Pcap file?

Hello @m.hariss123

When doing a transfer, your provider is returning 403

This happens often due to incorrect credentials, IP address restrictions, or insufficient account balance
You need to check with Twilio support

Hi Team,

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.

Twilio -> Retell/LiveKit: INVITE
Retell/LiveKit -> Twilio: 200 OK
Twilio -> Retell/LiveKit: BYE

We’ve also reviewed the SIP trace on our end and confirmed that no REFER request is present in the call flow.

Because of this, our /refer webhook is never triggered, and the transfer does not proceed.

Could you please confirm:

  • Does Retell support SIP REFER for call transfers over Twilio SIP trunks?
  • If yes, are there any settings required to enable it?
  • If not, what is the recommended way to handle transfers in this setup?

TwiML

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial
        referMethod="POST"
        referUrl="https://app.stammer.ai/en/voice/api/v1/inbound-call/refer/">
        <Sip
            statusCallback="https://app.stammer.ai/en/voice/api/v1/inbound-call/completion/"
            statusCallbackEvent="completed"
            statusCallbackMethod="POST"
        >
            sip:+13135139372@5t4n6j0wnrl.sip.livekit.cloud;transport=tcp
        </Sip>
    </Dial>
</Response>

refer endpoint code here

more notes

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.

Please help us figure this out. This is an urgent issue and is impacting our platform, and 5 customers left because the transfer wasn’t working.

@shaw can you please escalate this?

Hey @m.hariss123

I’ve escalated this issue again to our team for further review.

We’ll keep you updated as soon as we have more information.

Best regards

Thanks i’ll set it and test and let you know

@shaw @Omar_Ashraf
Thanks for the support. This fixes the issue.

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