How do I get access to the calls with unknown-erro...
# support
g
They are not triggered to the server automatically so I cannot manage them with the webhook and I cannot find the way of getting the endedReason with the Get Call request either. My goal is to access and store a table similar to the one in the "Call Logs" (under the new "Observe" section) but I do not find the way to do it.
v
I understand you're trying to access calls with "unknown-error" status that aren't being triggered to your server via webhooks, and you want to create a table similar to the "Call Logs" in the "Observe" section. To help you better, could you tell me if you've tried using the "GET List Calls" endpoint (
https://api.vapi.ai/call
) with specific query parameters to filter for calls that might have ended with errors? This endpoint allows you to retrieve multiple calls and might provide more filtering options than the "Get Call" endpoint. Also, have you checked if the
endedReason
field is available in the response from the "List Calls" endpoint? Sometimes different endpoints provide different sets of data fields. Sources: - [API Endpoints for Calls](https://docs.vapi.ai/api-reference/) - [Call Logs Table Columns](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1341746304744685599)
g
Getting List Calls does not solve the problem. All the calls brought are always in status=qeued so I do not have access to the endedReason=unknown-error.
In case you need it, here's a Call Id example but I am plenty of them: 7d7d3089-34dd-410a-898f-d7ec51da8c2c.
k
Okay
To help track down this issue, could you share one or two: - When exactly this happened (the timestamp) - What response you expected to get - What response you actually got instead This would really help us figure out what went wrong!
g
Thanks. I sent you one case, here there are few more: - 20d83573-8ed5-4190-b653-7941b67cade1 - 7d7d3089-34dd-410a-898f-d7ec51da8c2c - 485bd292-f6ea-4da3-a9b1-a4e55dd11dc3 - dd6721c6-f1d6-43c9-ac89-bb48ddccdcf5 - 1a33d4e0-c13c-4e4f-963a-6c2251763749 - b740a88c-5881-41b9-9fcc-0997044dc8e4 - 847921f4-8997-40ec-9821-89208602fd05 - cc049298-3d7c-4ff3-bb36-745b306d9c63 - f75a5c5e-e40a-4ac2-a53e-01014fe0efad - fed69651-1d0f-4e71-a973-e53315627e8b - 63f2378f-98a1-4a5d-b4b8-1b567371b866 - 81d2fed0-b59a-4d7f-a77a-75129a8753c3 But I think I do get why it happens, at least in some of those cases. Argentinian phone numbers are a mess; we need to add a 9 if I call a mobile phone. The funny part of it is that we can't tell by any means if the phone number is a mobile or not. So, we need to try first with the 9 (because it is usually the principal case) and then delete the 9 in the phone numbers and call the landlines. But this is a story we are used to managing with other systems. The problem is that we cannot get the logs by the webhook or the GET Call, which ended with an unknown-error. If I do the Get Call request, the only information available is "status":"queued" and no "endedReason". The same happens with Get Call List. I need that information that is actually viewable in the dashboard. So, I presume there is a way to rebuild the same table. I have not even found clues on how to do it with VAPI.
@Kings_big馃挮, it is not that I want you to push more pressure but I am still praying to get a workaround.
k
Looking into it
馃數 23:03:48:986 Call
b740a88c-5881-41b9-9fcc-0997044dc8e4
Waited 300s But Transport Never Connected. The log message
Call waited 300s But Transport Never Connected
reveals the actual technical problem. What's happening: 1. When Vapi initiates a call through Twilio, it waits for a transport connection to be established 2. In these cases, the system waited 300 seconds (5 minutes) for Twilio to connect the call 3. The transport connection never established, so the calls timed out 4. These calls ended with "unknown-error" status because the system couldn't determine exactly why Twilio failed to connect This explains why you saw calls with "unknown-error" in the dashboard but they showed as "queued" in the API - they were stuck in an intermediate state where Twilio never properly connected the call. This has been repeating for all of your calls. You have to check with the Twilio team regarding these call failures, and if it's related to your Argentina phone numbers issue that you've mentioned.
g
Thanks for your work and reply! It is confusing to read that it waits for 5 minutes when I see the unknown-error nearly immediately after making the failed call. If you can identify them in them dashboard, how can I do the same then? Should I consider calls with status queued as such?
Making up alternatives, I tried adding the following into the "transportConfigurations" but I got an Error 400... it seems that I cannot set up a webhook to receive Twilio's statuses. "statusCallback": "https://hook.us1.make.com/nkbe...", "statusCallbackMethod": "POST", "statusCallbackEvent": ["completed"]
I need to know and identify when these calls are failing and you are the ones receiving this information through VAPI. I really need support.
@Kings_big馃挮, did I lose you?
k
No I've forwarded your report to the executive will give you feedback soon, thanks for your patience
g
Thaaaaanks!
Hi @Kings_big馃挮! any news?
s
Hey, I just looked into all of your shared call IDs. These calls aren't connected from Twilio's side. Basically, if they didn't reply us within the required time, it leads to a timeout, and it says "transport never connected". And because of this, there was no progress on these calls leading to unknown status. For verification, you can use the Twilio call ID shared in the screenshot and check in your Twilio console as well https://cdn.discordapp.com/attachments/1360613373330460692/1368239378010210465/image.png?ex=68177fb8&is=68162e38&hm=1f02bb7112e33330d90f54b9cf3a03fc4666da946e129389681bb4394a3f7ace&
2 Views