Sip inbound calls are ending in 30 seconds.
# support
e
Sip inbound calls are ending in 30 seconds. Today we are facing this problem. Are there anybody has the same issue?
c
Thanks for reaching out about your SIP Trunking setup! You can find step-by-step troubleshooting help here: 👉 [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk) If that doesn’t resolve it, please reply with: - Your Call ID - The exact error message or behavior (e.g. 401 Unauthorized, timeout, etc.) - Whether it’s happening on inbound, outbound, or both trunks - Any recent configuration changes Once we have that info, we can help pinpoint the issue faster.
v
Thank you for sharing the issue. To help diagnose why your SIP inbound calls are ending after 30 seconds, could you please confirm if you see any specific error codes or messages in your call logs or SIP provider dashboard when the call drops? Sources: - [Vapi Call Ended Reason Documentation](https://docs.vapi.ai/calls/call-ended-reason) - [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk)
e
Hello, it is not our sip provider specific issue. Because we have another customer and they are working with different sip provider. And they have the same problem.
In vapi pcap file, we saw that there is no ACK packet received from our sip provider. We talked with them and they said, "we are sending ACK packet but in vapi side maybe there is an update, because the ip is same but port is changing after 5060. So the new port can't receive ACK packet.". Could you please check your site? They send us that your standard was: 44.229.228.186:5060 but recently it is routing to 44.229.228.186:51841 . Could you please check your side?
c
Hi tunamicacc, It sounds like there may be an issue with the SIP port configuration on our side. If your SIP inbound calls are ending after 30 seconds and you're not receiving an ACK packet from your SIP provider, it's possible that while the IP address remains the same, the port has changed, which can affect packet routing. To address this: 1. Verify that your SIP trunking setup is properly configured to handle non-standard ports besides 5060. 2. Check if there have been any recent configuration changes on your end or updates from your SIP provider. 3. Look for any specific error codes or messages in your call logs to help diagnose the problem. If these steps don't resolve the issue, please provide details such as your Call ID and any specific error messages or unusual behaviors so we can investigate further. You might also want to ensure that all relevant ports are open on your firewall and that your SIP provider is aware of the potential for dynamic port assignment. For more detailed guidance, please refer to our [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk).
n
@User The problem here is a little different. VAPI uses a load balancing scheme, which distributes the load between internal servers, while changing the in-dialog SIP signalling IP numbers. If the provider in place uses an SBC that has strict-signalling configurations, namely - DO NOT ALLOW CHANGING OF IP SIGNALLING for an established session - the 30 second disconnect will occur, just like with a missing ACK with NAT based configurations.
c
Hi, You may also consider these approaches: Option 1: SIP Provider Selection Switch to a provider that's more tolerant of mid-dialog IP changes: - Plivo - Uses unique SIP domains and may handle this better - Telnyx - Has been tested with Vapi's architecture - Twilio - Generally more flexible with SIP signaling variations Option 2: Authentication Method If possible, avoid IP-based authentication entirely: - Use username/password authentication instead - This may reduce the SBC's strict enforcement of IP consistency Providers like Plivo and Twilio may be less affected because they: - Use dedicated SIP domains per customer - Have more flexible SBC configurations - Are specifically tested with Vapi's load balancing architecture This is fundamentally an infrastructure compatibility issue that requires either provider-side configuration changes or switching to a more compatible SIP provider.
a
We have this working in SA if anyone needs help.
n
@awen1s We have it working all over the world 🙂
d
We are not seeing a 30-second drop or missing ACK. Our SIP trace is: INVITE -> 100 Trying -> 200 OK -> ACK -> immediate BYE and caller hears “phone number not found.” Assistant ID exists and is valid. Please check Vapi-side ingress/org association + trunk credential/routing mode for our account (SIP Direct vs DID routing), and share the exact URI format we must send from Twilio.
c
Hi, can you share the call id please or the SIP Invite url you are using so I can look into it