Setup: - Inbound calls via Twilio SIP trunk configured as byo-phone-number in Vapi - Server-side webhook handling

assistant-request

- Responding with

destination: { type: 'sip', sipUri: 'sip:+1XXXXXXXXXX@<twilio-sip-trunk-domain>' }

to immediately forward the call without an assistant Expected behavior: Call is forwarded to the SIP URI, same as it works for Vapi-managed phone numbers. Actual behavior: Vapi responds to Twilio's SIP INVITE with 603 Decline (~2s, 0 connect duration). The call is never forwarded. Confirmed via Twilio call insight logs (

last_sip_response_num: 603

). What we ruled out: - The

destination

response is correctly received by our webhook and returned to Vapi (logged) - TWILIO_SIP_TRUNK_DOMAIN is correct and reachable (verified with a SIP capture proxy — Vapi never attempts to dial the SIP URI at all) - Not a 403/auth issue — the 603 is immediate and deliberate - Works fine on Vapi-managed phone numbers with the same response format Question: Is

destination

in

assistant-request

responses intentionally unsupported for byo-phone-number SIP trunk calls? If so, what is the recommended way to immediately forward an inbound byo-phone-number call without spinning up an assistant? The

phone-call-control

forward works but requires the call to be in-progress first.

can you plese confirm these details about your setup 1- The (Inbound) failures are mostly because wrong creds. the connection should be via: correct SIP URI--->{phoneNumber}@.[sip.vapi.ai](http://sip.vapi.ai) ref: [https://docs.vapi.ai/advanced/sip/sip-trunk](https://docs.vapi.ai/advanced/sip/sip-trunk) 2- Check what is configure here: • if outbound/inbound both checked -- issue • if outbound checked and domain name or ip address is given--- no issue • if inbound checked and domain name is give --issue https://cdn.discordapp.com/attachments/1513980305030119487/1513989849911267388/image.png?ex=6a29bc6c&is=6a286aec&hm=9eaa297c3312c9770db99119958a374a854407c02e360538ee95a5d4ca55b6aa&

Updated the origination URI to include the credential ID (sip:f9e1df62-fbcb-4795-8193-c5d5f3666a0c.sip.vapi.ai) — no change. To clarify the scope of the issue: - Inbound calls work fine — calls reach Vapi, assistant-request fires, AI handles the call normally - Mid-call transfers work fine — forwarding via phone-call-control (using the control URL) works correctly for byo-sip-trunk calls - The only broken case is returning

destination

in the

assistant-request

response to forward the call immediately without an assistant Key finding from our debugging: We set up a SIP capture proxy and pointed our SIP trunk domain at it. When we return

destination: { type: 'sip', sipUri: '...' }

in the

assistant-request

response, Vapi never attempts to dial the SIP URI at all. It sends 603 Decline back to Twilio immediately (~2s, 0 connect duration) without making any outbound attempt. Core question: Is

destination

in

assistant-request

responses supported for byo-sip-trunk calls? If not, what is the recommended way to immediately forward an inbound byo-sip-trunk call without an assistant? phone-call-control requires the call to be in-progress first.

Can you share the call ID where you faced this issue?

@Priyanshu Ranjan were you able to look into this?

Apologies for the delay here Could you try the immediate-forward alternative: a

call.ringing

phone-number hook with a

transfer

action, and let me know if that works for you Docs: • [Phone Number Hooks](https://docs.vapi.ai/phone-numbers/phone-number-hooks) • [Server events](https://docs.vapi.ai/server-url/events)

That doesn't work, because we might forward on specific conditions that we calculate on our backend.