1

I am building an Interactive Voice Assistant using Twilio. My goal is to record parts of the conversation, process the recorded audio and

This is the answer to the /voice webhook (the one will receive Twilio's call)

<Response>
    <Play>./welcome</Play>
    <Record maxLength="10" action="/processing" recordingStatusCallback="/getRecording"></Record>
</Response>

Processing the audio and providing an answer may take a long time, so I added a Pause at the end of /processing:

<Response>
    <Play>./ok</Play>
    <Pause length="10"></Pause>
</Response>

This is the answer when finished with /getRecording

<Response>
    <Play>./answer</Play>
    <Record maxLength="10" action="/processing" recordingStatusCallback="/getRecording "></Record>
</Response>

/welcome, /ok and /answer lead to corresponding audio files.

So I was able to execute all steps, I can check in my logs that /getRecording is actually executed to the end and the twiml sent back again, but the /answer after /getRecording is never executed by Twilio (and the call just ends).

Do you have any guidance for it? Does Twilio accept multiple recordings on the same call?

Note: For some reason, if instead of using the 'recordingStatusCallback' I use /getrecording as 'action' it does work... but then we wouldn't be sure the recording we are using is really generated, right?

Thank you for your help!

Jose Lopez
  • 67
  • 6
  • Your first sentence seems to be missing something – Andy Apr 25 '17 at 04:20
  • @Andy it seems the syntax is ok, at least it works for me. The problem was as philnash explained below we can't send a new twiml in the /getRecording webhook, but actually redirect the call to a different one once the process is complete. Thanks! – Jose Lopez Apr 25 '17 at 20:15

1 Answers1

2

Twilio developer evangelist here.

Your /getRecording endpoint is called, however that is an asynchronous webhook in the context of the call. Returning TwiML to the recordingStatusCallback will not affect the current call.

Instead, you should use the REST API to modify the call by redirecting it to the next TwiML you want to execute based on the response to the recording file.

Hopefully the recording does take less than the 10 second pause that you are using, but you may want to add a loop into your /processing endpoint so that the call won't hang up on your caller. You can do this by redirecting the caller back to the start again:

<Response>
    <Play>./ok</Play>
    <Pause length="10"></Pause>
    <Redirect>./processing</Redirect>
</Response>

Then, when you get the recording callback you redirect your caller out of this loop.

Let me know if that helps at all.

philnash
  • 70,667
  • 10
  • 60
  • 88
  • thank you, that's exactly the solution we were looking for, it makes sense. I have moved the /getRecording twiml to a different /sendRecording, which is redirected after the audio processing and it works. Also thanks for the tip on the looping, it is specially useful since that way we also play different messages to the user, depending on how much the processing takes. – Jose Lopez Apr 25 '17 at 20:09