voice: voicemail/answering machine detection

[mastercactapus]

Is your feature request related to a problem? Please describe:

• When GoAlert leaves a voicemail the beginning of the message is cutoff
• The UI doesn't distinguish between a voice call being delivered to a person or an answering machine

Describe the solution you'd like:

• Display something like Delivered: completed (likely voicemail)

• Wait until voicemail message completes before speaking the message

• if a digit is pressed, assume a human

• if it was an answering machine, possibly mark it as a failure for retry

Describe alternatives you've considered: n/a

Additional context: Twilio does have AMD (answering machine detection) which now apparently supports async operation. Previous attempts were met with an unacceptable delay before the user heard anything.

https://www.twilio.com/docs/voice/answering-machine-detection

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[mastercactapus]

Probably worth spending a little time to test behavior locally -- even non-async with a 3-sec delay to not talk over the answering machine and maybe make some better decisions based on the AMD feedback.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[AlaricWhitney]

@mastercactapus I've used AMD quite a bit, and with Twilio, the answer is a bit nuanced.

• Twilio voice status messages will respond with completed when answered by a human or voicemail (https://support.twilio.com/hc/en-us/articles/223132547-What-are-the-Possible-Call-Statuses-and-What-do-They-Mean-)
• Enabling AMD will change the behavior of calls, in that when a call is answered, there will be silence until a human says "hello". If there is no "hello" detected within 3 seconds, it assumes an answering machine has answered (in which it'll wait until any opening speech is done and there's the DTMF tone indicating that it can start (or the detection times out). It's not perfect, but in practice what I've found is that if you add a 300-1000ms delay before starting to play the message, it avoids the issue of starting playback too soon most of the time.
• The AMD feature does expose if it's answered by a human mid-call, so you can play a different message or change the phone logic. My recommendation would be if AMD does not detect if answered by a human, to not solicit a response, but at minimum to play the issue at hand so someone can still know what the issue is and possibly log in online to acknowledge it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.