Hey Vapi team. We are completely blocked. We use a BYO SIP Trunk. Our carrier actively blocks/drops

SIP REFER

requests. We desperately need to do a blind transfer to a SIP URI using the DIAL verb (Bridging) instead of REFER. The system currently drops the call with a

BYE

when we try to force

sipVerb: dial

on a BYO trunk. Is there any feature flag you can enable on our org (

959b692f-b36c-4461-8335-c959c4290cad

) to allow Bridging/Dial transfers on BYO SIP Trunks? We cannot use Twilio in Argentina due to prohibitive costs. Thanks, Gerónimo

Unfortunately, Vapi currently only supports SIP REFER for blind transfers on BYO SIP trunks—there is no feature flag or documented method to enable DIAL/bridging transfers in this scenario. If your carrier blocks REFER, transfers will not work, and the system will drop the call as you've observed. For more details, see the [SIP trunk documentation](https://docs.vapi.ai/advanced/sip/sip-trunk). If you need this feature, please contact Vapi support to request it as a product enhancement. Sources: - [SIP Trunking Documentation](https://docs.vapi.ai/advanced/sip/sip-trunk) - [Debug call forwarding drops](https://docs.vapi.ai/phone-calling/in-call-control/transfer-calls/debug-forwarding-drops)

That’s a tough spot, especially if your carrier blocks SIP REFER. In situations like this, the transfer usually needs to be handled through a DIAL bridge instead, and the BYE drop you’re seeing could be related to how the BYO trunk negotiates the bridge. I can help you work through a setup that avoids the REFER issue. are you dialing the SIP URI directly in the DIAL verb or routing it through your carrier trunk endpoint? @Gerónimo

Hey @Ramsey y, thanks for jumping in! You absolutely nailed it. Our carrier (IPLAN) replies with

202 Accepted

to the

REFER

but then immediately drops the call internally. To answer your question: We want to dial the SIP URI directly to our destination PBX (

sip:1139891900@69.42.70.228

), completely bypassing the carrier trunk endpoint for the transfer leg. The issue is that because we are on a

byo-sip-trunk

credential, the

transferCall

tool seems to default to sending a

REFER

back to the carrier. We even tried using

mode: "warm-transfer-experimental"

to force a bridge, but it didn't seem to work as expected. How exactly should we structure the

destinations

JSON array in the

transferCall

tool to force Vapi to do a DIAL bridge (direct INVITE) to that external SIP URI instead of sending a

REFER

? Any JSON snippet or configuration tip would be a lifesaver!

could you please share a call id where the call dropped when you forced

sipVerb: DIAL

for the transfer?

Hey Kyle, thanks for stepping in! We actually hadn't successfully forced sipVerb: dial yet because we weren't sure if it was supported in the JSON for BYO SIP trunks. Following your message, I just updated our

transferCall

tool to explicitly include

"sipVerb": "dial"

and pointed it to our destination SIP URI (

sip:1139891900@69.42.70.228:5060

). I just made a test call and it dropped right after the transfer was initiated. Here is the fresh Call ID for this exact test:

019cfb29-1610-7aaa-b935-35bff8010355

Could you check the backend logs for this call and see why the DIAL bridge is dropping? We are trying to completely bypass our carrier (IPLAN) for the transfer leg because they block REFER. Really appreciate your help!

Since you want to bypass the carrier and dial the SIP URI directly, you’ll want to use a DIAL-type destination in the transferCall destinations array rather than relying on REFER. Here’s an example: Json code { "destinations": [ { "type": "dial", "sip_uri": "sip:1139891900@69.42.70.228", "caller_id": "+[your-caller-id]", "timeout": 30 } ] } Key tips: type: "dial" ensures Vapi initiates a direct INVITE instead of sending a REFER. sip_uri must point to your target PBX. caller_id can be set to the original caller or a specific identity. timeout defines how long Vapi waits for the call to be answered before failing. With this setup, the transfer leg should go straight to your destination PBX, completely bypassing the carrier trunk. @Gerónimo

Hey @Ramsey y and Kyle, Thanks for the tip! We really want to use the

type: "dial"

destination to force the B2BUA bridge and bypass our carrier's REFER block. However, when trying to patch our

transferCall

tool with that exact payload, the public API rejects it with a 400 Bad Request. Here is the exact error from the API:

JSON
{
  "message":[
    "each value in destinations.type must be one of the following values: assistant, number, sip, step"
  ],
  "error": "Bad Request",
  "statusCode": 400
}

It looks like

dial

is not exposed in the public schema enum for

destinations.type

. Is there a different way to format this JSON to force the DIAL bridge using

type: "sip"

, or is

type: "dial"

a feature flag you need to enable on the backend for our Org (

959b692f-b36c-4461-8335-c959c4290cad

)? We are standing by to test this end-to-end as soon as we can save the destination. You guys rock, thanks!

ah, i see the issue now. you're trying to transfer a call from a webcall, which is not compatible for transfers. try using the transfer on a SIP or PSTN call instead of web.

No, I'm not. I'm trying to transfer on a PSTN call.

my mistake. i was looking at the wrong call id.

sipVerb: dial

is enabled by default, but if what you said earlier was true about the carrier replying with a 202 accepted, then REFER is actually a valid method for IPLAN. The issue may be that IPLAN accepted the REFER but then couldn't route the call to your target PBX at 69.42.70.228 (since that's a direct IP outside their network), causing the call to drop after the handoff. Could you check with IPLAN whether they can route to that destination, or try a test REFER to a number/endpoint that IPLAN can natively reach, to confirm whether REFER itself is actually working and the problem is specifically with routing to that external IP?