VAPI disconnecting calls at 31 seconds length
# support
j
This morning VAPI is disconnecting SIP calls when exactly at 31 seconds. PCAP analysis shows that VAPI returns a BYE SIp message to our PBX at exactly 31 seconds. There's audio on both ways, looks like a timeout problem from VAPI side.
v
Thank you for sharing the details of the issue with SIP calls disconnecting at exactly 31 seconds and the BYE SIP message from VAPI. I understand how unexpected call drops can be frustrating, especially when audio is working both ways. While I don't have specific information available about this particular behavior or its cause, your detailed description of the timing and the PCAP analysis is very helpful for further investigation.
p
Analyzing more pcap files we can see that the server with IP 172.31.9.106 is the one which is hanging up calls. The server 172.31.57.86 works right.
Right server returns:
@Vapi Support Bot anything about this?
v
Thank you for sharing the detailed analysis and the differences you've observed between the two servers. It's clear from your PCAP findings that the server at 172.31.9.106 is consistently disconnecting calls at 31 seconds, while 172.31.57.86 is not exhibiting this behavior. The Contact URI details you've provided for both servers are helpful for further comparison. While I don't have specific information available about why this is happening or whether the Contact URI differences are directly related to the call drops, your thorough investigation is a great step toward identifying the root cause.
p
@Vapi Support Bot any way to avoid being attended by the faulty server?
v
At this time, I don't have any information available about how to avoid being routed to a specific server or how to control which VAPI server handles your calls. If any details about server selection or routing become available, I'll be sure to share them.
p
@Vapi Support Bot How many servers are serving at sip.vapi.ai? can I call directly to one of the IPs specified in nslookup sip.vapi.ai ?
v
At this time, I don't have any information available regarding how to avoid a specific server, direct calls to a particular IP, or configure SIP call routing in VAPI. If you have any other questions or need clarification on a different topic, feel free to ask!
p
We've banned IP 44.238.177.138 and service is working right with server on IP 44.229.228.186
@Vapi Support Bot what do you think about this?
v
It sounds like your approach to ban the problematic IP address (44.238.177.138) was effective, as your service is now stable with the other server (44.229.228.186). This indicates that the disconnects were likely tied to the server you blocked, and your solution has resolved the issue for now. If you notice any further changes or issues, feel free to share more details!
p
@Vapi Support Bot will it be fixed by your Support Team?
v
You've done a great job identifying the source of the SIP call disconnects and taking action by banning the problematic IP, which has helped stabilize your service. At this time, I don't have information about whether or when the issue with the server or IP will be fixed by VAPI's support team.
p
I'm going to bed then.... @Vapi Support Bot will I dream?
v
Thank you for sharing your detailed analysis and the steps you took to address the SIP call disconnection issue. It's great to hear that blocking the problematic server's IP has stabilized your service. If you have any further observations or updates, feel free to share them.
p
Crap, still failing
Contact URI is wrong
n
I've seen this earlier and reported as well. The issue is exhibited on a single VAPI application server, as far as I can tell.
k
Please send your call id
p
Call-ID: 36225b2f5422cbbb3eb405f73486182d@52.209.132.9:5060
for example
there are many of them
URI Contact Id is incorrect as shown in captures. Our Asterisk sends ack to that IP
This one
Internal server ip: IP 172.31.9.106
k
Looking into it
p
Thank you. Meanwhile we have entered 44.229.228.186 as sip.vapi.ai manually on hosts and banned the failing server. (44.238.177.138)
n
@pasamelo Limiting your signalling to a specific VAPI host and/or banning specific internal VAPI servers won't help this kind of situation. The way VAPI performs internal routing of sessions, to internal servers, is something you have no control over - and this will result in more failed calls, per your description. There are various aspects to resolving such issues, but they require some changes to the way VAPI handles their inbound SIP connections and also, how do the manage internal routing - which is very much managed by Jambonz internals.
p
After our measures everything is working
Just need confirmation from VAPI Support that the host has been fixed
n
I know from another thread it was fixed
p
can you point me which thread?
Anyway I can confirm that each host is assigned an unique external IP , the fix was working
Anyway Nir, the final fix was to define in /etc/hosts the desired resolution so that requests were always attended by the selected host. Ban the server Ip was a security measure so that this server could never attend our calls even in the case that was the selected host.
v
checking if this is resolved/solved for you?
v
Please reach out to us if you have any other questions regarding this issue