https://vapi.ai/ logo
Join Discord
Powered by
Support Request – Transfer Call Not Working (ISDN ...
# support
g
Hello, I’m currently experiencing an issue where the Transfer Call from VAPI is not passed through to an ISDN number. Nothing happens — no ringing, no signal, no call handoff. I have tested the following: transferCall function -forwarded call forwarding -Implementation directly inside the code → In all cases, the call does not reach the destination number. Additional information: -I am already in contact with both the ISDN provider and Zadarma. -So far, neither provider has been able to identify any issue on their side. Technical details: -Routing is done via Zadarma SIP trunking - Target is an ISDN phone system - Example call IDs for your review: CALLID_1 019aa563-239b-788c-a679-661af52c7e2e CALLID_2 019aa574-d33e-7cc5-aaf4-8986ad0859e3 Could you please check whether this could be a routing or compatibility issue on VAPI’s side? Thank you! https://cdn.discordapp.com/attachments/1441359300260790302/1441359300646670357/image.png?ex=6941ceb4&is=69407d34&hm=2855e23430be93e3f73905b2f24d1208973cc44a51769af3ba757f4070814dff&
v
Thank you for the detailed information. To help diagnose the issue, could you confirm if your Zadarma SIP trunk and ISDN system both support the SIP REFER method, and if SIP REFER is enabled in your configuration? This is required for VAPI's transferCall function to work correctly with ISDN targets, as VAPI uses SIP REFER for call transfers (see documentation: https://docs.vapi.ai/phone-calling/transfer-calls/debug-forwarding-drops). If you are unsure, you may want to check your SIP trunk settings or consult with Zadarma to verify SIP REFER support. Source: - [Debug call forwarding drops (Vapi documentation)](https://docs.vapi.ai/phone-calling/transfer-calls/debug-forwarding-drops)
g
Hello Vapi team, I have prepared a short technical summary (see attached PDF) describing an issue with transferCall when forwarding calls via SIP trunk (Zadarma) to a customer’s ISDN PBX. I have already tested several variations (different assistants, destinations, and test scenarios), and I can provide further JSON logs, pcaps or configuration details if required. I would kindly ask you to verify on your side whether, in the problematic scenario, the transfer leg is actually initiated at all or if the call never goes out towards the ISDN destination. In the attachment, all phone numbers have been partially anonymized for privacy. Thank you very much for your support. Best regards, Gerald https://cdn.discordapp.com/attachments/1441359300260790302/1441718722665648218/Vapi_Transfer_Call_Stellungnahme.pdf?ex=69446ef1&is=69431d71&hm=fc7a0c16e98bf537857e6729998a1d01d0dc976956c4aae43e1c818bde4c0625&
This summary reflects the official statement from Zadarma regarding the call behavior. The call transfer to +43 670 308XXXworks without any issues. However, during the call that should have been transferred to +43 3613XXX, Zadarma confirmed that no REFER packet was received from Vapi at any point. According to their analysis, one possible explanation is that the number +43 3613 2312 7362 is two digits longer than the other destination number, which might cause Vapi to reject it. Zadarma cannot confirm this with certainty, but they highlighted it as a potential cause. We kindly ask the Vapi team to verify this behavior on your side.
Hello Vapi team, I would like to forward the summary that I previously shared on Discord, as this message contained important technical details regarding an issue with the transferCall function. Issue description The transfer from VAPI to an ISDN destination number (routed via Zadarma SIP trunk) is not completed. No ringing, no call setup, and no SIP REFER are observed on the provider side. I have tested several variants: transferCall function forwarded call forwarding implementation directly inside the assistant code → In all cases, the call never reaches the ISDN destination. Provider statements Zadarma has confirmed the following: The transfer to +43 670 308XXX works without any issue. However, during the call that should have been transferred to +43 3613 XXX, no SIP REFER was received from Vapi at any point. Zadarma mentioned that one possible explanation might be the different number length (the ISDN number being two digits longer). They cannot confirm this, but highlighted it as a potential cause. Call details for review CALLID_1: 019aa563-239b-788c-a679-661af52c7e2e CALLID_2: 019aa574-d33e-7cc5-aaf4-8986ad0859e3 Request Could you please verify on your side whether Vapi attempted to initiate the transfer leg in these cases, or whether the REFER was never sent out? If possible, I would kindly ask for an official statement regarding: Whether differing number lengths could affect REFER initiation. Whether the REFER was generated at all for the two call IDs above. Any known compatibility limitations when transferring calls from Vapi → Zadarma SIP → ISDN PBX.
c
g
Hello Kyle, thank u so much. I would like to provide a clear technical summary regarding the transfer issue, now including the SIP trace (see attached screenshot), which confirms the behavior observed during the in-call transfer attempt. * The normal inbound call works perfectly* The initial call from the external caller to the voicebot establishes without any issues: * INVITE → 200 OK → ACK * RTP stream is established * The call is stable and functional There is no problem with the main call leg. 2. The issue occurs only during the in-call transfer (transferCall / SIP REFER) As shown in the screenshot and confirmed by our Wireshark capture: VAPI sends a fully valid 
REFER
The SIP trace clearly shows: * Correct Request-URI * Proper E.164 formatting * Correct dialog parameters and tags * Standard-compliant in-dialog REFER * Valid Replaces/Call-ID context Zadarma replies with 
202 Accepted
❌ But no further SIP activity occurs The SIP trace shows that after the 202 Accepted, the provider does not initiate the transfer at all. Specifically, there is: * no new INVITE toward the destination number +43 3613 XXX * no Replaces-based dialog * no second call leg 4. Summary The main call leg works perfectly. The issue is strictly related to the in-call transfer process, where Zadarma: * acknowledges the REFER (202), but * does not initiate the required INVITE to the target number +43 3613 XXX. We kindly ask whether: * Zadarma has known limitations with SIP REFER, * specific SIP trunk configuration parameters are required, or * alternative transfer methods (e.g., INVITE with Replaces) are supported. Thank you for your assistance.
c
Hi Gerald, Thanks for the detailed technical summary. Very helpful. Zadarma may have limitations or requirements around handling REFER-based call transfers. It would be best to contact Zadarma support directly and confirm: - Whether they fully support SIP REFER for blind transfers on your specific trunk - Whether any special configuration is required on their end - Whether number length or formatting affects REFER handling - Whether blind transfer flows (REFER → INVITE) are supported for ISDN destinations Because Vapi only sends a REFER during blind transfer, and we can see in your trace that the REFER was sent correctly and accepted, the next step definitely lies with Zadarma’s processing of that REFER. If you get any technical feedback from them and want us to take a second look, feel free to share it here — happy to help interpret it. Best regards, Vapi Support
PreviousNext
Powered by