Outbound calls failing via API on Twilio Connected...
# support
b
I'm having issues with outbound calling via API. Call is placed, I answer, but it immediately hangs up. When I look at TWILIO logs, I see the error 31920 - Stream - WebSocket - Handshake Error. When I look at cal logs, VAPI says that the customer did not answer (I did). I've been successful in the past with the same API call structure but to VAPI numbers, but when I switch to trying with a VAPI number the same issue occurs... Please help me unblock – this is holding back a pilot program that is set to start tomorrow! No mention in docs on how to handle something liek this.
Sample call ID here: f88c7a7f-7c19-4583-b516-e5cd62801736
a
I faced the same exact issue.
b
Did you get it resolved? or still an issue?
@Kings_big💫 – this one on your team's radar?
Response from twiliio support shows that when I hang up, the hang up action is immediately triggered and then the connection fails because the call is not in progress. On VAPI's side this shows as Customer Did not Answer (wrong), and Twilio sees this error after: https://www.twilio.com/docs/api/errors/21220 The error 31920 suggests we Verify WebSocket protocol is enabled in the server Verify the path in TwiML URL is actually the one supporting WebSocket But that's all handled on VAPI's side https://cdn.discordapp.com/attachments/1392159299123282012/1392246435688222750/image.png?ex=686ed608&is=686d8488&hm=55d7e5c883c6b50020a7c3a86306166cf58219dbc285ffb3eb3c76127f21cad2& https://cdn.discordapp.com/attachments/1392159299123282012/1392246436011311216/image.png?ex=686ed609&is=686d8489&hm=5e8f3e07328a0c576f9e611dd5ddf287619864c20fdf7285a055cfa15e935f49& https://cdn.discordapp.com/attachments/1392159299123282012/1392246436355248231/image.png?ex=686ed609&is=686d8489&hm=1f4572efd1d27588686f14a286f335e842228da87224f81284e476218cf85015&
h
well then we are screwed
my hang up rate is increasing now its at 55%
b
Found somsething interesting – I'm able to get through ONLY when the First Message Mode is set to "Assistant speaks first with model generated message". For "User speaks first" --> Fail, the case in this thread. For "Assistant speaks first" --> I pick up, there's about 5 seconds of silence, then the call is disconnected Seems like this is an issue with ordering who gets access to the websocket first? Again this should be handled by the VAPI call api?
h
that is interesting
b
Flipping that switch between the different modes seems to be promising – i'm getting through but the connection is terrible. Going to keep testing.
h
okay thats odd yeah
if thats the case im going to switch my outbound assistant so it speaks first instead of user, like it just hangd sup lol and the no speaking time out setting is 30 seconds so no reason why it should be doing this https://cdn.discordapp.com/attachments/1392159299123282012/1392253616252780646/image.png?ex=686edcb8&is=686d8b38&hm=11fc395bf4dd4a348cb3ac0ef6bc2b205104119bb1a3b54239fc84e6b514797f&
Assistant speaks first with model generated message, gunna try this one instead
b
I flipped back to "User speaks first" and went through a few calls before it started sounding natural. again. No idea why this is working now....
h
what the hell lol
what gpt model are you using?
im on GPT 4o Mini Cluster
btw is the number your using from twilio a2p verified?
changes back
why vapi so buggy these days
c
Could you share a loom screen recording of the issue so we can investigate further?
b
I've "resolved" it by flipping through the first message options. you can check this call sid @kyle to look at what happened: f88c7a7f-7c19-4583-b516-e5cd62801736 I've also posted the twilio logs to see exactly what's going on
c
Awesome thank you for sharing that! I will put it in my notes as it could possibly come up again in the future and if you require additional support, feel free to reach out
2 Views