Маршрутизатор задач Twilio, статус изменения резервирования

Следуя руководствам по созданию маршрутизатора задач (рабочая область, очередь, работник, задача) и созданию задач с помощью телефонного звонка.
Я могу успешно выполнить вызов и создать задачу с помощью моего приложения node.js.
После добавления пользовательского интерфейса агента через tutorial @ Пользовательский интерфейс агента Добавить проект
Вот последовательность действий приложения:

  • Клиент звонит на номер Twilio
  • Голосовые сообщения Twilio в API-интерфейс Rest на Node.js
  • Голосовые сообщения Twilio в API-интерфейс Rest на Node.js
  • Создан Twiml, и пользователь получает подсказки
  • Пользователь выбирает вариант
  • Ответ отправляется в API Node.js, и задача создается

The above steps are success
On the client
Agent launches the node.js app with taskrouter.min.js and agent.js as provided in the sample above.
Customer gets the default hold noise, on the agent browser a series of events "reservation created, update and reservation cancels" are observed. Posting the console logs towards the end.

  • Наблюдение 1, клиент получает шум удержания по умолчанию, подтверждающий, что задача успешно создана через приложение. Задача также отображается в графическом интерфейсе администратора Twilio
  • Наблюдение 2. Получение последовательности событий «Резервирование», «Обновление», «Отмена» несколько раз.
Also Observed that the dateCreated, dateUpdated and dateStatusChangedare year1970 , 1970-01-17T17:52:39.413Z. Any pointers would be greatly appreciated.
[Edit:] I do see similar issues with the PHP Sample code as well. Found that the Date is not an issue. [Edit:] Reached out to Twilio Support, hoping to hear from them, no luck so far
[RESOLVED] Heard back from twilio support, thanks twilio. Issue was with the Assignment Callback URL on the Workflow. My API was /Get. Changed it from Get to Post, to make it work. As the assignment URL was not reachable (via POST), task router was trying to cancel the reservation.


person tx fun    schedule 18.01.2016    source источник
comment
На каком этапе вы принимаете бронирование? Если вы не примете бронирование вовремя, в зависимости от ваших настроек, время ожидания истечет.   -  person ecorvo    schedule 19.01.2016
comment
Прежде чем я смогу принять бронирование, клиент получает запрос на отмену, думая, что мне, возможно, придется установить тайм-аут для принятия при создании задачи. Я получаю резервное событие на клиенте, несколько миллисекунд, получаю событие изменения статуса и событие отмены. и я снова получаю эти 3 события через несколько миллисекунд   -  person tx fun    schedule 19.01.2016
comment
Проверьте время ожидания резервирования задачи рабочего процесса. Это то, что вызывает тайм-аут, если резервирование не принимается в установленные сроки. Сообщите мне, если это поможет.   -  person ecorvo    schedule 19.01.2016
comment
Итак, вы упомянули, что получаете событие обновления бронирования. Где-то в вашем приложении вы должны обновлять бронирование. Любые идеи?   -  person ecorvo    schedule 20.01.2016
comment
используя Agent.js в пошаговом руководстве. Activity.Update запускает состояние агента в автономном режиме в состояние ожидания. Когда задача создана, статус по умолчанию переходит в Отмена, а изменения зарезервированы. WR1 Agent One отменен 22:22:37 UTC 2016-01-19 WR Agent One отменен 22:22:37 UTC 19.01.2016 WR3 Agent One отменен 22:22:38 UTC 19.01.2016 WR4 Agent One ожидает 22 : 22: 38 UTC 2016-01-19 AcceptRejectAbove - это изменение статуса Twilio Create Task, GUI. Статус по умолчанию отменен, что мне кажется странным.   -  person tx fun    schedule 20.01.2016
comment
Вы можете разместить свой код? Конкретно на стороне агента.   -  person ecorvo    schedule 20.01.2016
comment
Я попробовал образец PHP, и он размещен на c9 @ test2go-flashking.c9.io/test /agent.php, в котором также есть код на agent.js. См. Тот же образец, вызов переходит в состояние отмены, а затем зарезервирован. В конце концов отменяется.   -  person tx fun    schedule 20.01.2016


Ответы (2)


Сотрудник Twilio здесь.

Это результат того, что TaskRouter может поразить ваш AssignmentCallbackUrl запросом HTTP POST. Мы заметили, что в вашем аккаунте есть это сообщение с уведомлением:

Невозможно выполнить POST / присвоение

Включите POST для конечной точки AssignmentCallback.

TaskRouter будет активно отменять резервирование, если он не может поразить ваш AssignmentCallbackUrl или если при выдаче инструкции назначения возникает ошибка.

Несколько обновлений в консоли связаны с тем, что TaskRouter отменяет резервирование из-за того, что не попадает в AssignmentCallbackUrl, перемещает Worker обратно в предыдущее состояние (доступно), а затем пытается снова назначить задачу и, таким образом, создает другое резервирование для рабочий для той же задачи (повторяйте 15 раз, пока не будет достигнуто максимальное назначение задачи).

person Justin Witz    schedule 02.02.2016

Получил ответ от службы поддержки Twilio, спасибо Twilio. Проблема заключалась в URL-адресе обратного вызова назначения в рабочем процессе. Мой API был / Get. Изменил его с Get to Post, чтобы он работал. Поскольку URL-адрес назначения был недоступен (через POST), маршрутизатор задачи пытался отменить резервирование.

person tx fun    schedule 03.02.2016