Twilio Voice API порядок вызова url и statusCallback с включенным определением машины - PullRequest
0 голосов
/ 26 сентября 2018

При выполнении вызовов twilio у нас есть параметр url и statusCallback, например:

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();

здесь )

Яс трудом выясняет, вызывается ли url перед statusCallback или наоборот?

Я вижу, что когда machineDetection включен в вызове (как дано здесь ) если Answered_by равно machine_start, то statusCallback называется до * url (который поставляет тимл).

Хотя в одном случае я обнаружил, что если machineDetection включен и Answered_by был human (т. Е. Он обнаружил, что человек отвечает на вызов), я увидел url, вызванный первым.

Так каков ожидаемый порядок вызова url и statusCallback?(Предполагая, что у меня настроена statusCallback для вызова для текущего вызова)

1 Ответ

0 голосов
/ 27 сентября 2018

Евангелист разработчиков Twilio здесь.

Из документации по звонкам , есть еще некоторые подробности о statusCallback:

URL, который Twilio будетотправлять асинхронные веб-запросы на каждое событие вызова, указанное в параметре StatusCallbackEvent.Если событие не указано, Twilio отправит завершено по умолчанию.

Параметр StatusCallbackEvent может быть установлен на любое или несколько из инициированных, вызывающих, отвеченных и завершенных.

Поскольку у вас нет настройки события, вы используете событие completed по умолчанию.Это событие должно быть запущено после завершения вызова.Если вы видите, что он срабатывает до вызова вашего URL, используете ли вы другие события?

Другое дело, что эти события запускаются асинхронно по отношению к вызову.Даже если событие ringing сработало, к тому времени, когда ваш веб-сервер ответит на него, вызов может быть завершен.Таким образом, я бы программировал для защиты состояния вызова, не предполагая, что вызов определенно выполняется.

Более четко: события запускаются асинхронно, поэтому вы не можете гарантировать, что обратный вызов answered будет запущен до или после получения параметра url.

...