Twilio Studio Flow is having a problem with transitioning to the next widget when a user disconnects the phone. This causes the phone number used to not receive further calls as Twilio keeps the execution alive with that phone number. This is causing massive issues!
To explain the scenario/problem - When Twilio successfully calls the user and the user answers to start going through the flow, the user disconnects the call towards the end of the flow, after the hangup event is triggered on the widget, the flow manages to move through a couple of widgets after this, however stops on a widget which causes the execution to get stuck as the call is not being disconnected I assume. The widget it get's stuck on is a Say/Play and has an autocomplete which should move to the hangup function.
Here are some images to help with my explanation...
Image of the logs:
Image of the widget which the call is stuck on:
Best approach for this is to open a support ticket for them to investigate further. Twilio does have a programmatic way of ending an execution here but ideally it wouldn’t be in a stuck state to begin with.
Update an Execution
Understanding and Avoiding Stuck Executions in Twilio Studio
Related
Dear Connectycube Team,
I hope this email finds you well.
Our company has integrated Connectycube into our application, which primarily relies on video calling for communication between users and service providers. To ensure a seamless user experience, it's imperative that the video calling system is robust and reliable.
Unfortunately, our development team is facing challenges in making the system highly robust and 100% reliable. The issue lies in the connection dropping when the application is killed or the phone is locked.
issue: We are trying to integrate connecticube onto cordova app. We are using callkit to implement native incoming screen. The issue is that whenever the app is killed or the phone's screen is locked, accepting the call on callkit leads to failure since the accept call function gets called before the connecticube oncall event listener is called.
I would like to request a call with your technical team to discuss this matter and receive any insights or recommendations that could improve the video calling system.
Thank you for your assistance.
Best regards,
Kanhu
Once we receive incoming call using callkit and the user accepts the call, we try to send the accept call command to connectycube. But since the oncall event is not fired immediately, we create a callback loop to wait for the oncall event to get fired. This works sometimes but fails most of the time. Is there any other way ro achieve the accept call functionalities using callkit and connectycube on cordova.
I started creating a Twilio MVC project yesterday and only have one issue that I need to have resolved.
I am needing to be able to download the recording created by Twilio and process it using Azure Cognitive Services and in the event that the audio does not match, I need to redirect to another action within the MVC project while the call is still active.
Everything works perfectly until the action that handles failed attempts at authentication is called multiple times. I am able to set a breakpoint within the action that performs the verification and once the execution of the code resumes, there are no issues. Obviously, there is a race condition.
Has anyone else successfully implemented something similar?
Is the only option to cause the thread to sleep for a bit? Should I rely upon the callback and re-initiate a phone call in the event that the verification fails?
Is it possible to detect a call ended in studio?
I have a studio flow that performs a call to a number (this is the first step and it is configured with the make outgoing call widget). The problem is that i am not able to detect if the call ends once the call is connected, the widget itself allows detecting if busy or failed.
I want to know if it is possible to detect call end event so i am able to react to this in my app. Or be able to start an outbound call using call resource api and after the call is connected guide my user through the flow steps (I only have a phone number if that matters)
Thanks.
Studio does not expose the StatusCallback so you are aware of the status of the call. You can build this outside Studio and configure the StatusCallback URL to be alerted to the call state. You can fine more details here, Set StatusCallback on an outbound call.
I have a Twilio Studio flow that uses the "Gather Input from User" during an outbound call.
I have widgets following all possible outcomes, including "No Input".
However, I have discovered that if the user hangs up during this step, the flow ends.
I need to capture the fact that the user hung up, but I can't figure out how.
Any suggestions?
Twilio developer evangelist here.
For an outbound call from the Studio widget there is no way to capture status events as you would for a call normally. There are two workarounds though.
Firstly, if you are recording the call then you can set the recording status callback, which will notify you once the recording is ready and thus the call is over.
Alternatively, you will need to poll the Studio REST API to keep an eye on running executions and when they finish.
I'm running into a problem with an app that I'm building that I'm a little stuck on.
I have an iOS app (handles initiating the call via Twilio SDK) that communicates with a Ruby on Rails back-end (handles the Twilio server side implementation) to enable communication between the iDevice and the phone number being called.
The issue I'm having is that when a call is initiated accidentally (user error or misunderstanding how the app works) and the user goes to terminate the call Twilio has already received the request to create the call and it still goes through.
I've tried disabling the TCConnection and the TCDevice using their respective disconnect methods ("disconnect" and "disconnectAll"), but I'm still seeing the call go through (phone number being called still receives the call from the Twilio side of things). I haven't tried anything on the server side of things because I'd like to avoid building a set of "oh &$^$%" protocols if I can avoid it.
Has anyone experienced this before? Does anyone have any suggestions? Is there anyway to terminate calls made accidentally?
Thanks in advance!
Checking back in to share what I've discovered after reaching out to Twilio support in the event anyone finds this in the future.
From Twilio support:
For canceling a call, you can use the REST API to modify the live call and set the Status to "completed", which will cancel a ringing call and end an established call:
https://www.twilio.com/docs/api/rest/change-call-state
So, in short, build some "oh #^%$*" protocols that you can ping as necessary to actively terminate any call that you need to. Not ideal, but the options are limited.