We need to pass context from our servers to VAPI and return this context back. The only way I know is to use SIP and pass SIP headers around. But after forwarding our call to a VAPI SIP phone (e.g.

sip:somusername@sip.vapi.ai

), we cannot make VAPI to forward back the call using SIP: https://cdn.discordapp.com/attachments/1329106554041012265/1329106554330550334/vapi-sip-outbound.png?ex=67892270&is=6787d0f0&hm=715fdef6951f247c0eba29b14a34b7c5541c0f02ff6b1cc20bc1188cbf7c0dff&

@Manuel Saelices To pass context from your servers to VAPI and ensure that the context is returned back, you can indeed use SIP headers to carry this information. When forwarding a call to a VAPI SIP phone, you can include custom SIP headers to pass the context. However, if you're experiencing issues with VAPI not forwarding the call back using SIP, it's important to ensure that your receiving system is properly configured to handle SIP REFER messages, as VAPI utilizes SIP REFER to transfer SIP calls. If you've confirmed that your system is configured correctly and you're still facing issues, it might be necessary to look into the specific implementation details and any error messages you're receiving. If you need further assistance with this, please provide more details about the problem, and I'll do my best to help you resolve it. If the issue persists, you may need to reach out to support for more in-depth troubleshooting.

@VAPI Tech could you help me?

@Manuel Saelices Yes, i can help you.

@Manuel Saelices you can try importing your own twilio number and in the payload we forward all of your sip headers as well. Do let me know how it goes.

Not sure what do you mean.

@Manuel Saelices You can forward the call to another SIP provider, and can pass SIP Headers as well.

How we can instruct the VAPI assistant to forward the call in the payload or prompt?

[1] https://docs.vapi.ai/call-forwarding [Prompt-Instructions] trigger the transferCall tool with [2] > I tried by adding a SIP target with sip:... URI and it did nothing Could you share the call id so I could take a look?

@Shubham Bajaj sure. this is an example of failed call:

921d59f4-726b-4f0e-9453-cc32ba9b4496

@Manuel Saelices looking into it.

You are right, I've found the pcap session and this is the error Twilio raised: https://cdn.discordapp.com/attachments/1329106554041012265/1331545828040642630/image.png?ex=67920230&is=6790b0b0&hm=02d127ed94e0a890c7a86b8a439b97cc3ca52ea56b781b801d85313a64c6158a&

Hi there, I'm new here please excuse my question if it is not up to the standard. I would like to tell the AI model to say "All calls are recodred for quality and training purposes" but in a machine-like sound, so it feels like a recorded message in a different tone / voice if possible How to do that in VAPI AI model? i use the native VAPI model with blocks, so the first block content is "All calls are recodred for quality and training purposes" Do you recommend another way?

Hey @Manuel Saelices you need to add the refer verb within your transfer request by default we don’t add it. Which you can find over here, https://api.vapi.ai/api under TransferDestinationSIP.

@Shubham Bajaj I don't get it. It says that it's the default one: https://cdn.discordapp.com/attachments/1329106554041012265/1331740349667737673/image.png?ex=6792b759&is=679165d9&hm=bc9f99ca11c57576ed5d7e17afd55bba3f6eb9aab043aad43201136c5dfda8b6&

@Manuel Saelices To provide some context, you are routing calls from the Twilio SIP trunk to us via Jambonz. We have instructed Jambonz to send you a SIP REFER to facilitate the call transfer, however, it appears that Twilio may be expecting something that we are not currently providing, which has led us to create this ticket for you. At this juncture, I have a few questions for you: - Is this issue causing any blockage for you? - What specific outcome are you aiming to achieve? - You have the option to import the number to us, so I would like to understand the rationale behind using Elastic SIP Trunking.

The need is to pass certain IDs between call legs back and forth. We can pass IDs to VAPI via SIP but, when there is a hand-off, we do need to pass that ID back to us to be able to match the call legs. If we don't use SIP refer, we can't pass any data.

@Manuel Saelices You may utilize the transfer-destination-request server event, which allows you to determine the appropriate destination for the call transfer. Additionally, this server event will provide you with SIP headers. Would this information be beneficial to you?

How can we identify which call comes to Twilio during a transfer? We need to know that the Twilio call SID CAxyz correspond with a previous call SID CAabc. Is the new Twilio call SID passed as part of the transfer-destination-request payload?

@Manuel Saelices Verification Of Context:- 1. First Call to VAPI:    - The initial call (Call Leg 1) is routed to VAPI from Twilio or another SIP provider.    - This call includes a custom SIP header (e.g.,

X-Call-ID

) that carries an identifier (e.g., Twilio Call SID for Call Leg 1, such as CAabc). 2. Second Call (VAPI to Destination):    - VAPI forwards the call to the destination (Call Leg 2), creating a new Twilio Call SID (e.g., CAxyz).    - The relationship between these two call legs needs to be established using the identifier passed in the SIP header (e.g.,

X-Call-ID

). 3. Association Between Call Legs:    - The identifier passed in the SIP header during Call Leg 1 (CAabc) allows the system to associate it with Call Leg 2 (CAxyz). Possible Solution:- 1. Custom SIP Header:    - Pass

X-Call-ID: <unique-id>

in the SIP headers for Call Leg 1. 2. VAPI and Transfer-Destination-Request:    - When VAPI triggers a transfer-destination-request event, your server receives this event.    - The event payload includes the SIP headers, allowing you to extract

X-Call-ID

. 3. Transfer and Correlation:    - Use the extracted

X-Call-ID

to determine the transfer destination.    - After the transfer is completed and Call Leg 2 is established, correlate the new Twilio Call SID (CAxyz) with the original Call SID (CAabc) using the

X-Call-ID

identifier. Notes 1. This approach works because the custom SIP header (X-Call-ID) acts as the bridge between the two call legs. 2. PSTN to SIP transfer is not available,  using Vapi.

That's correct, but what if we receive two calls at aprox the same time from the same origin phone (e.g. an shared office number) to the same destination number, so we create two calls, eg CA001 and CA002. Then, both calls are transferred to us at the same time, so we have two legs CA003, CA004. How we can know if CA003 is the second leg of CA001 or is the CA002 one? And same question for CA004.

@Manuel Saelices Isn't generating truly unique ID for every originating call leg (e.g., UUIDv4) will work for you?

I mean the Twilio Call SID. In the POST data for incoming calls in Twilio webhooks, we only have the data sent by Twilio which is Twilio Call SID, from number and destination number. So how can we match those second leg calls from same number to the same number at the same time?

@Manuel Saelices a quick call, will get it done?

Sure. Could be in five minutes?

@Manuel Saelices check your DM, let's do it over the call.