https://vapi.ai/ logo
Join Discord
Powered by
Transfer to Internal Number on SIP Trunk
# support
f
I have successfully configured the AI Voice agent to make outbound calls and receive inbound calls to/from external numbers through the SIP Trunk. I would also like the AI Agent to be able to call/transfer calls to internal numbers on the SIP Trunk PBX. When transferring calls using the transfer call tool. If I use the SIP Trunk number and extension, it goes to the main entry point to the PBX and the extension is ignored. If I use just the extension number as a phone number, it uses that as if it is an external number and the call fails. Is there some additional configuration I should be aware of to route AI Agent transfer calls to internal numbers on my PBX (VoIPline)? I've contacted my PBX provider and they indicated they didn't see a request to transfer the call, so it seems to be coming in as a new call? From their support: "According to the logs, we can see the call was answered by the SIP Trunk, but we didn't see any evidence of a call transfer"
v
To transfer calls to an internal PBX extension, configure your transferCall tool to use the SIP URI format and ensure SIP REFER is enabled on your SIP trunk. For example:
Copy code
json
{
  "type": "transferCall",
  "destinations": [
    {
      "type": "sip",
      "sipUri": "sip:101@your-pbx-domain.com"
    }
  ]
}
Replace 
101
with your extension and 
your-pbx-domain.com
with your PBX's SIP domain. Make sure SIP REFER is enabled in your PBX and SIP trunk settings for transfers to work as intended (according to the documentation I have found: https://docs.vapi.ai/advanced/sip/sip-trunk). Source: - [SIP Trunking Vapi Documentation](https://docs.vapi.ai/advanced/sip/sip-trunk)
f
Further investigation by my PBX provider indicates that the SIP Registration call is still going out on port 5060, despite 7060 being configured through the dashboard.
Outgoing call traffic is working correctly, but incoming traffic can only be performed with the SIP URL, rather than directly on the SIP Trunk.
This is making it difficult to do transfers.
My PBX Provider also requires FQDN for the gateway but when I try to use this for incoming calls when creating the SIP trunk, I get an error.
Some further details: * Outgoing SIP Trunk calls to my VoIP provider must use FQDN, so when configuring the SIP Trunk, I have to include one gateway with the FQDN; however, when using the FQDN in creating the trunk/credentials, I cannot also enable incoming calls on that gateway without getting an error when creating the trunk/credentials (bug in validation?). * Incoming SIP Trunk calls from my VoIP provider use a Netmask/24 address range, so I have to include one gateway with the IP/mask, however cannot enable outgoing calls on that gateway, as it will cause errors when making outgoing calls due to the lack of FQDN (bug in gateway selection?). * During network tracing, it was determined that VAPI was sending the register request via port 5060, rather than the configured 7060. This means that my VOIP provider never received the REGISTER call, and the registration is ineffective (bug in registration call?). So, to support incoming/outgoing calls, separate gateways are required, and calls to the VAPI AI agent use a SIP URI @.sip.vapi.ai rather than details in a SIP registration. This means I can call the VAPI AI Voice Agent, and the VAPI AI Voice Agent can call out, but calls to the VAPI AI Voice Agent cannot transfer calls to internal numbers on my VOIP provider.
What I'd like to see: * The registration call to go out to the configured domain on port 7060 as configured in the domain field - so that my VOIP provider can correctly direct calls to the VAPI AI Voice agent over the SIP Trunk rather than a separately configured SIP URI; * The ability to whitelist the Netmask 24 addresses for incoming INVITE calls without impacting the configuration for outgoing connections to my VOIP provider to always use FQDN gateway. I believe if those two things can be sorted out, I should be able to enable transferring of calls to internal numbers on my VOIP provider. If I've misunderstood something, please let me know.
PreviousNext
Powered by