Twilio: Don't want to keep logs of voice callers' numbers - twilio

I use Twilio to operate an automated phone line that connects callers to resources for some very sensitive topics. If the phone numbers of callers were revealed due to a data breach or subpoena, it could have negative consequences for them. There's no need for us to log callers' numbers, and ideally I'd like to not store that information at all. However, these numbers show up in my usage logs:
I've searched for ways to prevent these numbers from being logged or to delete them after they've been logged, but I can't find anything documented. Is there a way to do this?

Partial answer: You can delete the record of a call using the API DELETE functionality:
DELETE https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Calls/{Sid}.json
You can have a script periodically request all calls made to the number and call DELETE for each one. If your system involves recordings, transcriptions, or texts, you need to do the same for them.
This is an acceptable solution for our needs, but it would be ideal if the numbers weren't logged in the first place, so I'm still interested in hearing others' answers.

Related

Amazon Connect with Lex contact flow timeout

I have a contact flow that is using a pre-recorded voice prompt with a lex bot for voice rec. This is the main menu verbiage:
“Thank you for calling. If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen to the following menu options. For billing questions, say “billing”. To report a missed pickup, say “missed pickup”. If you are a current customer with recycling or other account questions, say “other”. If you are not a current customer, and have questions, say “sales”. To hear the menu again, say “repeat menu”. For all other questions, please remain on the line.”
I have set the error handling in the Lex bot to speak "Sorry, I'm having a hard time understanding you. Let's try using the keypad instead to make sure we route your call properly."
This is working when an utterance is not matched or an invalid option is spoken or pressed. However, I cannot figure out if it's possible to allow the lex bot to timeout like in a normal DTMF contact flow and send the caller to the next step in the menu without playing the error handling in from the Lex bot.
Is this possible?
That's the thing, Lex is not meant to be used this way. It MUST have an input to process, and if it reaches Lex's timeout, then it will always return an error and deliver the error handling response.
So you will have to get fancy in the Connect Flow to catch the Lex error message, and turn it into your own handling of it. But it will be hard to know whether Lex is erroring because it didn't understand, or because the user chose not to respond.
Therefore, I would personally avoid building the bot in a way that allows the user to remain silent. The user must direct Lex every step of the way and have easy ways of backing out of an unwanted action.
Remember that Lex is much more powerful than the old automatic call systems, so trying to force Lex into that old system won't work well. Depending on how you design your bot, you can make the conversation much much more natural, accepting a very wide range of responses and directing those into proper actions.
Tips:
Things may have changed more recently, but when I was building Lex/Connect, it was not possible for the user to interrupt a playback message. So I had to also avoid what you are trying to do in the welcome message:
If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen...
Naturally, a user who does want to use the keypad will try to immediately say "keypad" and probably get frustrated by having to listen to the rest of the playback message. So I design every playback message to be short, deliver information first, and always end on the question. Often breaking the conversation up into more branching points to make the questions as specific as possible.
Don't worry about going back and forth with the user too many times. It gives the user comfort knowing they are on the right path to what they want and are able to control the conversation in smaller steps. They will get stressed, having to listen to long list of options and remembering what they are while figuring out which one best applies to them.
So make each question as clear as possible and avoid spoonfeeding options. It feels less natural to explicitly state to the user what they should say:
To report a missed pickup, say “missed pickup”.
That is unnatural.
A good middle ground would be asking one question with a list of options and pausing between each option. The user will understand that these are responses they should make, but won't feel unnaturally pressured into exact phrases. For example:
Would you like to, check your billing, report a missed pickup, ask about sales, or something else?
That is natural.
We are comfortable handling those types of questions because we often do that when speaking with humans. You may even want to use a question mark instead of commas so that the playback voice uses a questioning intonation with each option. It looks less natural in written form, but would probably sound more natural.
Last tip: Don't design your bot based on your experience talking with bots. Design your bot based on your experience talking with humans.

Unspoofing phone calls

So I get spoofed calls and they're annoying; however from a little reading it seems like all the spoofing is only done in the Caller ID field, but that there are additionally 2-3 ANI fields that generally are used for carrier billing that are much more difficult to spoof. I also have both legitimate friends and spam calls that use blocked numbers, and again it seems it's just Caller ID being left blank and ANI still being submitted. (please correct if this assumption is wrong/there's a better value to use instead)
My end goal is to set up a "public" number that I give out to people, and that "public" number would read the ANI data, "fix" the caller ID, then forward the call to my actual number/send me a text/notification with the real number. My understanding is this is possible if I internally forwarded the call to an 800 number I own first (then forward the number back to a non-800 number to avoid charges) but I haven't seen this mentioned in any Twilio/Bandwidth.com/etc APIs - they mention a 'from' field but not how that field is determined. I've seen products that do this like Trapcall so I know it's possible somehow, but would prefer not to forward all my calls to a number I don't control.
How do I do this? If I forward a call with a fake/blocked caller ID to an 800 number on Twilio/Bandwidth will the from number of that forwarded call be automatically corrected/unblocked? (And would I be able to compare the from of the original call to the from of the 800 call, where a mismatch would mean a spoofed number?) Or is there some specific way the 800 number has to be setup for this/the 800 numbers off of Twilio don't work at all/etc?
I also read that ANI is not very reliable on VOIP calls, and VOIP calls are more or less anonymous. Is there any way to find out whether an incoming call is being made from a VOIP service or from an actual landline/mobile? I know there's the Caller ID lookup, but if we assume that data is unreliable can we find out just from data made available during the call itself?
Figured it out, it does work from toll free #'s, it's just twilio specifically didn't work with it. worked with other providers.

Pattern for recording the price of Twilio phone calls

Would like to maintain a local record of the price of all the phone calls that my application makes.
Am not sure what a good pattern for this would be. It looks like the price is not available in the arguments provided during the status call back when the call is closed. I assume this means I'll need to query Twilio's servers to find the price of the call. Can I do this immediately or do I need to wait a certain amount of time for the price to populate?
Is there another pattern that would be simpler, require fewer steps, or be less error prone that I am not seeing here?
Thanks!
Twilio evangelist here.
I'd recommend checking out the Usage Records API. These handy API's give you an easy way to get rollup data for your account, like how much your account spent yesterday, or how many outbound calls it made.
You can also set up Usage Triggers to proactively notify you when threshholds are met.
Hope that helps.

Limit user to perform an action a certain number of times in a day

I am using Rails 3.1.0 with Devise 2.1.0. I would like to limit the number of times a user can perform an action in a day. The main purpose of this limitation is to prevent spam.
I see many questions similar to this one but was wondering if there is a specific way to accomplish what I am trying to do through Devise.
For the actions that create model instances, the number of times an action has been performed in a day is easy to keep track of. However, at least one action that I would like to restrict does not create a model instance, so I'm not sure what to do about it.
I was also wondering if this is a legitimate/effective way of preventing spam (in addition to requiring users to register and sign in to perform the actions).
Personally, I find these sorts of systems to be over-complications. Unless spam is an existing, provable problem I'm not sure adding in a system that's likely to be rather extensive is a good use of time and energy.
Alternatives to this would be requiring registration through a third-party service (say Facebook) and using either captchas or exciting and new negative captchas.
That said, if you want to do this, I think the best place to keep track of it would be in an ephemeral data store. Redis would be really good for this since you can use queues. In the actions that you want to restrict, add a timestamp to the queue, and before you allow the user to perform said action, check the number of elements in the queue, purging ones that are too old while you do so.
That's sort of pseudo-codey, but should at least help you get started.

Twitter app development best practices?

Let's imagine app which is not just another way to post tweets, but something like aggregator and need to store/have access to tweets posted throught.
Since twitter added a limit for API calls, app should/may use some cache, then it should periodically check if tweet was not deleted etc.
How do you manage limits? How do you think good trafficed apps live while not whitelistted?
To name a few.
Aggressive caching. Don't call out to the API unless you have to.
I generally pull down as much data as I can upfront and store it somewhere. Then I operate off the local store until it runs out and needs to be refreshed.
Avoid doing things in real time. Queue up requests and make them on a timer.
If you're on Linux, cronjobs are the easiest way to do this.
Combine requests as much as possible.
Well you have 100 requests per hour, so the question is how do you balance it between the various types of requests. I think the best option is the way is how TweetDeck which allows you to set the percentage and saves the rest of the % for posting (because that is important too):
(source: livefilestore.com)
Around the caching a database would be good, and I would ignore deleted ones - once you have downloaded the tweet it doesn't matter if it was deleted. If you wanted to, you could in theory just try to open the page with the tweet and if you get a 404 then it's been deleted. That means no cost against the API.

Resources