Small update while you investigate. We reproduced the same failure pattern with a second BYO SIP trunk provider. Provider A: Claro BYO SIP trunk - Outbound PSTN works - transferCall type:number fails - Destination never rings Provider B: IPLAN BYO SIP trunk - Outbound PSTN works - transferCall type:number fails - Destination never rings IPLAN test call ID: 019e4cbc-5c82-7cc0-ae45-1dda1fed3667 Result: endedReason: assistant-forwarded-call forwardedPhoneNumber: +5491156193561 Observation: Initial call connected and audio worked, but after transfer was initiated, the destination phone never rang and the call dropped. This suggests the issue is not specific to one carrier.

Hi! any news or update?

1. Standard Transfer & the Refer-To Domain When you use type: "number", Vapi’s SIP stack automatically formats the target as a standard E.164 number and defaults to appending the Vapi IP in the Refer-To header (e.g., sip:+number@). Your BYO carriers (Claro and IPLAN) are likely rejecting this because they expect their own domain or a specific format. • Supported Solution: You can fully control the Refer-To header by changing your destination type to sip. • Exact JSON: codeJSON

"destinations": [
  {
    "type": "sip",
    "sipUri": "sip:+5491156193561@your-carrier-domain.com"
  }
]

(If your carrier requires a strict tel: URI, you can also format the sipUri string as tel:+5491156193561) 2. Warm Transfer Leg Failure This was caused by the exact same URI domain formatting issue mentioned above. Changing the destination to type: "sip" with the proper carrier domain will fix the outbound INVITE for warm transfers as well. 3. Direct SIP URI Transport Error For Call ID 019e4c83-743f-7884-b9ef-afd6ed42147d, the call.start.error-get-transport error happens because our SIP stack cannot infer the transport protocol when a raw IP address is provided without a DNS SRV/NAPTR record. • Supported Solution: You must explicitly declare the transport protocol in the URI. • Fix: Append ;transport=udp (or tcp / tls) to the end of your SIP URI. • Example: sip:1139891900@69.42.70.228:5060;transport=udp 4. type: "dial" Support You are correct; type: "dial" is not supported for transferCall on BYO SIP Trunks. The public API validation is accurate, and the allowed destination types are strictly assistant, number, sip, and step. Update your transfer tool configurations to use type: "sip". Explicitly format the sipUri to include your carrier's domain, and if you are using raw IP addresses, ensure you append the transport=udp parameter. Let me know once you update the JSON to the sip type and run a test

Additional finding. Separate inbound issue. We also received the full inbound INVITE from Claro for the call that returns 404. SIP Call-ID: D242ABCE6E19A55816C8AA97@0b70ffffffff Incoming INVITE from Claro SBC: INVITE sip:1140071900@44.238.177.138;user=phone SIP/2.0 To header: [sip:+541140071900@44.238.177.138;user=phone](sip:+541140071900@44.238.177.138;user=phone) Source: 177.234.129.52:5060 Destination: 44.238.177.138:5060 Transport: UDP Vapi response: SIP/2.0 404 Not Found **Question: **For BYO SIP inbound routing, does Vapi match the incoming call against the Request-URI user-part (

1140071900

) or against the To header (

+541140071900

)? What exact

byo-phone-number.number

value should we configure so this INVITE routes to our assistant? Current hypothesis: The 404 is caused because Claro sends the Request-URI user-part as

1140071900

, while our Vapi phone number may be configured as

+541140071900

. Do we need to create or import the BYO phone number as

1140071900

with E.164 validation disabled, or should Vapi be able to match the To header E.164 value? Thanks.

Update after reviewing the PCAP from the controlled

destination.type = "sip"

transfer test. Call ID:

019e660b-58c7-7554-994f-4ed3398570a2

Configured transfer destination:

json
{
  "type": "sip",
  "sipUri": "sip:+5491156193561@ollsbc.tramavirtclaro.com;transport=udp"
}

PCAP shows that Vapi did send a SIP REFER to Claro:

sip
REFER sip:177.234.129.52:5060;yop=... SIP/2.0
Refer-To: <sip:+5491156193561@ollsbc.tramavirtclaro.com>
Referred-By: <sip:+541140071940@44.229.228.186>

Human result: * Initial outbound call connected. * Assistant audio worked. * Transfer was triggered. * Destination phone never rang. * Caller was disconnected. Important observations: 1. The actual

Refer-To

in the PCAP does not include

;transport=udp

, even though the configured

sipUri

did. 2. We do not see NOTIFY progress in the parsed SIP output. 3. Vapi sends BYE shortly after the REFER. 4. Vapi still marks the call as

assistant-forwarded-call

. Can you please confirm from your internal SIP logs: 1. What exact SIP response did Claro return to the REFER? Was it

202 Accepted

, 4xx, 5xx, or something else? 2. Did Vapi receive any NOTIFY for this REFER? 3. Is Vapi expected to send BYE immediately after REFER, even if the transfer destination has not rung yet? 4. Why was

;transport=udp

stripped from the configured

sipUri

in the actual

Refer-To

? 5. Does Vapi consider

assistant-forwarded-call

successful as soon as REFER is sent, regardless of whether the carrier completes the transfer? 6. Can we force alternative

Refer-To

formats, for example: *

sip:+5491156193561@177.234.129.52

*

sip:5491156193561@177.234.129.52

*

sip:+5491156193561@ollsbc.tramavirtclaro.com;user=phone

At this point the key question is no longer whether Vapi sends REFER. It does. The question is why the REFER does not result in a completed transfer or ringing destination.