1
votes

We are leaving a voice message (using an MP3) using Twilio's answering machine detection. We are seeing in our logs the correct calls to/from the API (answered by answering machine, post of our recorded message)...no error.

But the persons were are testing on, only 1/4 are actually getting a voicemail. The rest receive no voicemail, even though the logs show the correct API calls...? What is happening here?

Here is the code to call the twiml.

 if (Request.Form["AnsweredBy"] != null)
        {
            switch (Request.Form["AnsweredBy"])
            {
                case "machine_end_beep":
                case "machine_end_silence":
                case "machine_end_other":
                    SaveTwilioMessage(transaction.Campaign.Id.ToString());
                    //var machineResponse = new VoiceResponse();
                    if (!string.IsNullOrWhiteSpace(transaction.Campaign.VoicemailMessageUrl))
                    {
                        response.Play(transaction.Campaign.VoicemailMessageUrl);
                    }
                    else
                    {
                        response.Say(transaction.Campaign.VoicemailMessage, voice: _voice);
                    }
                    return new TwiMLResult(response);
                case "human":
                case "fax":
                case "unknown":
                default:
                    break;
            }

And here is the call that generates this:

 var call = await CallResource.CreateAsync(url: callbackUrl, to: new PhoneNumber(phoneNumber), from: new PhoneNumber(fromPhone),machineDetection: "DetectMessageEnd");
        var result = new TelephonicResource(call.Sid);
        return result;

Any thoughts?

3
Is the message playing out before the machine itself starts to record?philnash
I think this is possible, but this isn't how Twilio's AMD is supposed to work. I don't think I have the ability to write logic to listen for a stop or a beep. I could record a much longer message, and see if only a part of it gets left maybe? Their service is in beta - so I am expecting some hiccups but not like this.user3502355

3 Answers

3
votes

Twilio developer evangelist here.

When using Twilio's answering machine detection you have two options for detecting a machine. You set answering machine detection to on by supplying a MachineDetection parameter to the REST API request to make a call.

The MachineDetection parameter can be either Enable or DetectMessageEnd. If you want to leave a message after the answering machine message is complete you need to use DetectMessageEnd.

Then, when you get the webhook callback for the start of the call you get an extra parameter, AnsweredBy, which is either machine_end_beep, machine_end_silence, machine_end_other, human, fax or unknown.

If you get machine_end_beep, machine_end_silence or machine_end_other then you should be able to leave your message then. For other results you can handle them as you would a normal call.

If you just use MachineDetection=Enable then Twilio will attempt to connect you to the call with the result as soon as it has figured out if it is human or machine. If you want to leave a message, I would not choose this option.

Let me know if this helps at all.

2
votes

Answering my own question here. Finally got some support from Twilio after pushing up through sales - after ticket remained open and unworked for days.

Basically, if you want to pull off AMD successfully, you need to be able to respond within 150ms. On our calls, the voice mails were starting, detecting no sound, and saying "we're sorry, but you're not talking...then our message would start". The correction was to do less DB lookups in our API calls by changing programming practice, and moving our MP3 to somewhere on the East coast (AWS preferred).

We investigated this...and found that while our API response was taking ~1 second, the AMD was sometimes waiting 15+ seconds after the beep to play the message. Still confused.

1
votes

We are using Twilio AMD to broadcast phone appointment reminders, and have similar difficulty with leaving voicemail messages. Having tested this on about 50 calls, we see cases where the AMD detects a 'machine_end_silence' well before the 'beep' that should trigger the PLAY. So when you listen to the recorded call, the PLAY is occurring at the same time as the "your call has been forwarded to an automated voice messaging service...please leave a message...". So the API calls all look correct, but the user doesn't receive a voicemail (as the play message wav file ends just before the beep).

We saw other cases where the AMD doesn't hear the beep - and instead waits for the machineDetectionTimeout before playing the wav - leaving a long gap of dead air on the receivers voicemail. Even within my small development team we saw differences in behavior. For instance, we made test calls to a few iphones that all had the same default voicemail setup (the setup you get when you haven't recorded a custom greeting) on the same Verizon service plan. So the AMD should be hearing the exact same answer. Yet, AMD would detect the 'beep' on some of our phones, but not all of them.

Given all these challenges, we found that it's a good idea to leave a 'longer' version of the message (repeating the critical information a few times). Assuming your message is longer than the machineDetectinTimeout - you at least get some of your message saved on the voicemail.