Hi Vapi Support, We’re running into an issue with SIP transfers from an inbound agent to an ICR number. Flow: * A customer calls in. * The inbound agent answers. * The agent transfers the call to an ICR number. * On the receiving side, the call shows the agent’s number, not the customer’s number. We tried to work around this by using SIP headers on the transfer to pass the customer info through. Here is the transfer config we are using:

json
{
  "id": "7be0598b-e32f-4906-8518-d4679ea0c9d0",
  "createdAt": "2026-02-06T23:17:08.570Z",
  "updatedAt": "2026-02-09T18:57:16.238Z",
  "type": "transferCall",
  "function": {
    "name": "transfer_call_tool_sip"
  },
  "messages": [
    {
      "type": "request-start",
      "blocking": false
    }
  ],
  "orgId": "",
  "async": false,
  "destinations": [
    {
      "type": "sip",
      "sipUri": "",
      "message": "test",
      "sipHeaders": {
        "X-Lead-Id": "{{call.id}}",
        "X-Customer-Name": "{{first_name}} {{last_name}}",
        "X-Customer-Phone": "{{customer.number}}"
      },
      "description": "test",
      "transferPlan": {
        "mode": "blind-transfer",
        "sipVerb": "dial"
      }
    }
  ]
}

The problem is that the headers are being sent literally. For example, we receive:

X-Customer-Phone: {{customer.number}}

instead of the actual customer number. So right now: * The transfer shows the agent’s number, not the customer’s number. * The header variables are not being resolved and are sent as raw strings. Is there a supported way to: 1. Preserve the original caller (customer) number on the SIP transfer, or 2. Properly inject dynamic call variables into SIP headers during transfer? This is blocking one of our clients and is pretty frustrating on their end, so any guidance or workaround would help a lot. Thanks, Arman

Currently, Vapi does not support resolving dynamic variables (like

{{customer.number}}

) inside SIP header values during call transfers. The variables are only interpolated in prompts and messages, not in SIP header fields, which is why you see the raw strings. As a workaround, you may need to set the desired values explicitly in your transfer configuration or handle variable resolution in your own application logic before sending the transfer request. For more details, see the [dynamic variables documentation](https://docs.vapi.ai/assistants/dynamic-variables). Source: - [Dynamic Variables Documentation](https://docs.vapi.ai/assistants/dynamic-variables)

@arman this is same problem somebody else is facing, I am fixing for them. u should be able to get like this: https://cdn.discordapp.com/attachments/1470549189292458128/1470553317066145832/image.png?ex=698bb700&is=698a6580&hm=1646a9a2ffa809749b907bdc095a8d7d8e7d8ae175491b8d98f4eb79637f5477&

How did you fix it?

yes, its better in Twilio, texted u

Hey Arman, yeah this is a known pain point with Vapi right now SIP transfers don’t resolve variables in headers, so anything like {{customer.number}} gets sent as-is, and the caller ID falls back to the agent by default. The only real workaround at the moment is passing the customer info earlier through session metadata or webhooks and then rebuilding it on the receiving side before routing the call. If keeping the original caller ID is critical, it usually has to be handled at the SIP/carrier level using something like P-Asserted-Identity. Are you controlling the SIP endpoint yourself, or is this going through a third-party ICR provider? @arman