启用机器检测的Twilio语音api调用url和statusCallback的顺序

Question

While making twilio calls, we have a url and a statusCallback parameter like this:

client.calls
  .create({
     method: 'GET',
     statusCallback: 'https://www.myapp.com/events',
     statusCallbackMethod: 'POST',
     statusCallbackEvent: ['completed', 'answered'],
     url: 'http://demo.twilio.com/docs/voice.xml',
     to: '+14155551212',
     from: '+18668675310'
   })
  .then(call => console.log(call.sid))
  .done();

(From here )

I am having a hard time figuring out whether the url is called before the statusCallback or vice versa?

I see that when machineDetection is enabled in a call (as given here ) if Answered_by is machine_start then the statusCallback is called before the url (that supplies the twiml).

While in one case I found out that if machineDetection enabled and Answered_by was human (ie. it detected a human picking up the call), I saw the url called first.

So what is the expected order of invoking url and statusCallback ? (Assuming that I have setup statusCallback to be called for an in progress call)

Answer 1

Twilio developer evangelist here.

From the documentation on calls , here's some other detail about the statusCallback :

A URL that Twilio will send asynchronous webhook requests to on every call event specified in the StatusCallbackEvent parameter. If no event is specified, Twilio will send completed by default.

The StatusCallbackEvent parameter can be set to any or multiple of initiated, ringing, answered, and completed.

Since you don't have an event setup, you are using the default completed event. This event should be fired once the call is over. If you are seeing it fire before your URL is called, are you using other events?

The other thing is that these events are fired asynchronously to the call. Even if the ringing event is fired, by the time your web server responds to it, the call may be over. So I would program defensively for the state of the call, not assume that the call is definitely in progress.

More clearly: The events fire asynchronously, so you cannot guarantee that the answered callback will be fired before or after the url param is fetched.