Hi, I’m trying to use the Blind Transfer with Summary in SIP Header feature, but I noticed the summary comes through as a REFER. Is there any way to make it work with an INVITE instead? I’m running Asterisk 20 and 11 (currently testing on 11). The problem is, I can’t really get REFER working at all. In our setup we don’t usually use REFER for transfers. We rely on the PBX’s built-in * transfer, so having this available via INVITE would be super helpful. Thanks a lot in advance for any pointers!

Currently, Vapi's blind transfer with summary feature uses SIP REFER by default, not INVITE. However, a recent update introduced a new

sipVerb: "dial"

option in the

transferPlan

, which may offer alternative call handling. You can try configuring your transfer like this:

json
"transferPlan": {
  "mode": "blind-transfer",
  "sipVerb": "dial"
}

Note: There is no explicit documentation confirming that INVITE with summary is supported, so this may not deliver the summary as you expect. If this does not work, you may need to continue using your PBX's built-in transfer or consult Vapi support for further options. [See changelog reference](https://docs.vapi.ai/changelog/2025/3/2) Source: - [Vapi Changelog March 2, 2025](https://docs.vapi.ai/changelog/2025/3/2)

Message marked as helpful by @𝘬𝘴𝘻𝘢𝘣𝘪! 🎉

I tried what the @User suggested, and now the INVITE with the summary header is coming through as expected. The problem is that the new call doesn’t actually get set up. Vapi sends a BYE on the original call too early before Asterisk has finished establishing the new call leg. Is there any way to control this behavior? Ideally Vapi should only send the BYE after the new INVITE has been confirmed and the dialog is active. Can this timing be delayed or adjusted on the Vapi side, so the original dialog isn’t torn down prematurely? Thanks again for any help!

Hey! To help track down this issue, could you share: \- The call ID \- When exactly this happened (the timestamp) \- What response you expected to get \- What response you actually got instead This would really help us figure out what went wrong!

Hi Praveen, thanks for looking into this. Call ID: 7e623262-cd64-4137-ba58-e0924815d566 Timestamp: happened on Expected behavior: after Vapi sends the INVITE with the summary header, I expected the original call to stay up until the new INVITE is confirmed (200 OK + ACK) and the new dialog is fully active. Actual behavior: Vapi sends a BYE on the original call immediately, before Asterisk has finished establishing the new call leg. This tears down the transfer prematurely, so the new call never completes. So the main issue is that the BYE is sent too early. Ideally Vapi should only send it once the new dialog is successfully set up.

Hey, thanks for sharing your details. Our team will look into it and get back to you soon with an update.

Hey! Any update on this yet?

Currently, there is no configuration in Vapi to delay the BYE after sending an INVITE with summary in a blind transfer. The BYE is sent immediately, which can cause the new call leg to fail if the dialog is not yet established. Actionable next step: If this behavior is blocking your use case, please report it as a feature request to Vapi support, as this timing control is not currently supported in the platform's transfer logic. [See transfer documentation](https://docs.vapi.ai/call-forwarding) Sources: - [Vapi Call Forwarding Documentation](https://docs.vapi.ai/call-forwarding) - [Vapi Changelog March 2, 2025](https://docs.vapi.ai/changelog/2025/3/2)

Could you please provide a more recent call id so we can review the PCAP file?

0199a50f-1480-733c-b24d-92b5e6db08e3 0199a511-0916-733c-b24e-bc9b2fab79b9