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?
Related
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
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 writing an app using Parse which saves data to the server over a connection with unknown stability. As such I'm using saveEventually.
I'm trying to deal with the situation where the app is minimised, and then terminated by the system before a save is complete. The trouble is, when
opening the app afresh, I issue a logout command, since users are required to log in. It appears that this logout command can overtake the save commands, removing the session from the server, causing the queued save commands to fail. (I also can't see any way of handling these failures after an app restart, since I don't see any delegate based handlers, and blocks are cleared.)
I can't see any user-facing solutions to this either, since there is no guarantee when saveEventually might decide to run, and I can't block the user indefinitely.
Has anybody dealt with this? Any suggestions are most welcome.
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.