Vapi and Asterisk error when trying to transfer fr...
# support
r
Hello, I have been experiencing some unresolved problems on my side after many analyses.. It seems to me that it is a problem on the Vapi side when handling SIP telephony. The following happens: I configured an Asterisk server to receive calls and forward them to VAPI, however, I have experienced some instabilities during testing. It happens that sometimes the transfer occurs successfully, but simply out of nowhere, at some point during the day VAPI starts to refuse my calls, and at another time it starts accepting calls again. It's very fickle and I need a solution for it.
p
Hey! To help track down this issue, could you share: - The call ID This would really help us figure out what went wrong!
r
How can i get the call ID, if vapi rejected the call?
Now it is working fine again, so i cannot try to get the error message
But i know that in some hours, or tomorrow, vapi will respond it with rejection or any error again
And i will have another problem with customers
It is being very unstable..
p
Without the PCAP file or Call ID, I am unable to identify the issue you are experiencing. To unblock your account, I require either of these documents. Please inform me when you are able to provide them.
r
1b36256b-f629-4e97-8e5f-f86d46e111bd bad19138-f401-43fc-967c-ec5549240302 Could you check those?
I don't think the support I need involves analyzing the callids, since the call isn't even authorized by the vapi sip. Therefore, they don't generate any recording, since the call didn't even happen. I'm trying to get a window on Asterisk with my team to get the exact error and try to provide you with more context.
Could you please check why this call got timed out even with customer talking? 19e1172e0dce72b111d99aa63beec507@sip.vapi.ai
@Shubham Bajaj
@Shubham Bajaj Please help me, sometimes vapi returns error 500 when im transfering to vapi SIP from my asterisk..
80% of transfers it works
20% it returns error 500
2f52941906cfee1109fdbfc42082423a@sip.vapi.ai There is the call id im issuing problems.
You can focus on this one, only. This is the problem i've been having.
This is the same problem im having
How do i manage to fix it?
p
Rocha Looking into your issue.
Call ID: bad19138-f401-43fc-967c-ec5549240302 It looks like you’re analyzing a possible call termination issue related to a closed WebSocket connection. Here’s how we can refine this further: --- Call Termination Analysis - Frame 7:
200 OK (INVITE)
confirms the SIP server accepted the call. - Frame 8:
ACK
sent in response to
200 OK
, confirming call establishment. - No
BYE
Message in the Capture - A
BYE
request is needed for a proper call termination, but it's missing from this trace which resulted into
phone-call-provider-closed-webcoket-connection
- This suggests one of the following: - The
BYE
message wasn't captured. - The call was terminated due to an issue outside of SIP signaling. https://cdn.discordapp.com/attachments/1340082214146146435/1341710553416208475/rocha.pdf?ex=67b6fcd3&is=67b5ab53&hm=b3a159870624a2a67c0485689b05b755509b6b19ced9800fa3b1178ceae5de22&
1b36256b-f629-4e97-8e5f-f86d46e111bd This BYE request in Frame 10 is a SIP termination message. 35.198.23.153 (caller) is sending the BYE to 44.229.228.186:5060 (VAPI). The SIP call was established successfully (200 OK was received earlier), and then the caller (35.198.23.153) decided to end the call after about 6 seconds. The hang-up was intentional and normal (not due to network failure or timeout).
r
Thank you about that, @Shubham Bajaj
But i keep getting problems with the error 491 request pending from Vapi side..
p
Hey Rocha, can you share those call Ids? FYI: I am marking your ticket under Priority tickets.
n
@rocha I've investigated this issue a while back, and I believe the root cause of this issue is caused by Vapi's use of DNS round-Robin records for the
sip.vapi.ai
domain name. What I've noticed is that in some situations, the call is received at a specific gateway, then the SIP response comes from another server, which potentially just spun up and not yet has the active SIP dialogs populated to it. Again, this is only an assumption from my analysis. At Cloudonix, we created our DNS resolver, so we maintain the signaling of sessions based on the first request, maintaining a statefull session. Technically speaking, this method is in direct contradiction to the SIP RFC, which is why Asterisk and RingCentral will have issues with that. Again, based on my analysis, this seems like a race condition occurring during servers spin up or scaling at Vapi, but this is just an assumption - I can't confirm that this is an issue. BTW, if you wonder why I'm so familiar with Asterisk, look for my name in the source code 😀
8 Views