Call ID: 019d5567-eb02-7ff1-b2db-203015f5729c - Org ID: d9f124ca-637d-457b-a550-4a49636ca22e - Vast majority of our inbound calls are failing with that code "call.inprogress.error-providerfault-transport-never-connected"

To escalate this inbound call failure, please report the issue to Vapi support with your Call ID and Org ID as shown below:

Call ID: 019d5567-eb02-7ff1-b2db-203015f5729c
Organization ID: d9f124ca-637d-457b-a550-4a49636ca22e
Issue: Vast majority of inbound calls failing with error "call.in-progress.error-providerfault-transport-never-connected"

This will allow the support team to investigate the connection logs and assist you further, as recommended in the [issue reporting guide](https://docs.vapi.ai/issue-reporting). Source: - [Issue Reporting Guide](https://docs.vapi.ai/issue-reporting)

Hey @Phil that error usually means the call transport (WebRTC/SIP) never fully established, so the connection drops before the call actually starts. I can help you quickly debug this it’s often caused by webhook delays, misconfigured endpoints, or provider connection issues like Twilio/Vapi setup. If you want, share your setup Vapi config + provider + webhook flow, and I’ll pinpoint exactly where it’s breaking.

That error usually points to the SIP transport never fully establishing, so the call gets stuck before media/session negotiation even begins super frustrating, especially at scale. In most cases I’ve seen, it comes down to misaligned SIP signaling (REGISTER/INVITE flow), firewall/NAT issues, or the provider not accepting the transport handshake properly. I’ve helped debug similar Vapi + PBX setups and can walk through this with you directly to pinpoint where it’s breaking. Quick question are you seeing the transport fail during initial REGISTER, or only when the INVITE is sent for inbound calls? @Phil

Thank you Adam! I'm not an engineer on our team but running point on this... What do you need me to send you exactly? Apologies for my lack of knowledge in advance....

Let's connect i send you a friend request

Hey Matt, so not exactly sure but it's failing at moment the number is called, or if the agent does answer, it fails to complete the call altogether after just 15-20 seconds

That’s helpful, if it fails on answer or drops after ~15–20 seconds, it’s usually a SIP handshake or RTP issue (often NAT/firewall or missing ACK/keepalives). The short connection suggests media isn’t flowing properly or the session is timing out. @Phil

one-way silent before it drops

That confirms it one-way audio before drop is almost always an RTP/NAT issue. The call connects, but media isn’t flowing back, so it times out. I’d check NAT config (public IP in SDP), enable symmetric RTP, and ensure RTP ports are open/forwarded correctly. I can help you trace and fix this quickly end-to-end. @Phil

Sure

Do you have an email we can use to discuss this more privately? We can also schedule a quick call from there and sort it out together. @Phil

philip@zynix.ai

Hi, Thank you for your patience while we reviewed the recent phone number failures. The issue is a per-number provider-side transport issue, rather than a platform-wide problem. We recommend the following immediate checks: • Compare the SIP trunk configuration of the failing numbers against the working ones • Review the assistant configuration, since the failing numbers are using a different assistant (

f6248ebf...

) than the stable numbers (

e9c6c93f...

) • Verify your telephony provider dashboard (Twilio, Vonage, etc.) for any incidents, suspensions, or routing changes If the issue returns, the fastest recovery steps would be: • Re-provision the affected numbers by deleting and re-adding them in Vapi • Test each number individually with inbound calls • If only specific numbers continue failing, please contact your telephony provider and share the affected date range plus the impacted numbers