aharu 17 мар 2020 в 14:50

Asterisk и отправка пропущенных в Telegram/Slack/E-mail

4 мин

6.5K

Есть колл-центр. Есть Asterisk/FreePBX с настроенными очередями. Есть агенты, которые должны обслуживать вызовы. Но потенциальных клиентов так много, а агентов так мало, что первые никак не могут дозвониться до вторых — повисят-повисят в очереди минуту, да и отключаются.

Но зачем-то они же звонили! Может, они хотят денег занести в компанию? Попробуем вернуть и клиентов и их деньги на примере FreePBX.

В настройках очереди можно указать Fail Over Destination — то, куда направлять вызов, когда очередь переполнена, истекло время ожидания и т.п. Но зачастую бывает так, что звонивший отключается раньше, чем его успевает перенаправить в Fail Over Destination — мало ли, связь оборвалась. Готового решения для таких случаев нет. Поэтому идём под кат и пишем своё — с отправкой оповещения в Telegram/Slack/E-mail/куда-то там еще.

И первое, что нам надо понять — как FreePBX пишет логи очередей. В самом простом случае это текстовый файл /var/log/asterisk/queue_log.

Так в лог пишется обычный звонок от абонента 8964467ХХХХ, позвонившего по номеру 302221ХХХХ, попавшего в очередь №603 на первую позицию, которому через 8 секунд ответил Agent Girl. Они проговорили 133 секунды и первым трубку положил абонент — всем бы таких вежливых менеджеров!

1584318765|1584318747.89449|603|NONE|DID|302221ХХХХ
1584318765|1584318747.89449|603|NONE|ENTERQUEUE||8964467ХХХХ|1
1584318774|1584318747.89449|603|Agent Girl|CONNECT|9|1584318765.89450|8
1584318907|1584318747.89449|603|Agent Girl|COMPLETECALLER|9|133|1

А вот немного другая история, когда абонент 8996453ХХХХ дозвонился по номеру 302257ХХХХ, повисел 10 секунд в очереди №210 в первой позиции и отключился. Даже голосовое меню не дослушал!

1581728710|1581728690.59367|210|NONE|DID|302257ХХХХ
1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453ХХХХ|1
1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10

Вот про него-то мы и напишем в мессенджер.

Для этого нам надо отловить появление события ABANDON в файле лога. Я долго ломал себе голову как это можно сделать, но потом совершенно случайно наткнулся на прекрасный инструмент — MONIT. В нашем случае он будет следить за логом очередей, и как только в нём появится строка «ABANDON» будет вызывать скрипт обработки данного события.

Для этого после установки пакета:

yum install monit

Настроим его — создадим файл /etc/monit.d/queue_log и запишем в него буквально три строчки:

check file queue_log with path /var/log/asterisk/queue_log
    if content = "ABANDON" then
        exec "/var/lib/asterisk/agi-bin/qlogevent.sh $EVENT"

Таким образом, при появлении слова «ABANDON» в логе очередей, что говорит нам о преждевременном отключении абонента, будет вызван скрипт /var/lib/asterisk/agi-bin/qlogevent.sh с параметром $EVENT, что есть ничто иное, как полностью строка, в которой это слово появилось.
Это просто.

А теперь начинаются не шахматы — тут думать надо.

В строке, переданной в скрипт, отсутствует информация о номере звонившего:

1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10

В ней есть только Timestamp (1581728720), уникальный ID звонка (1581728690.59367), номер очереди (210), само событие и еще несколько несущественных параметров. Т.е. искать номер абонента придется нам самим. А каким же образом? А очень просто, ведь UID звонка у нас есть!

Обратимся опять к логу данного звонка, конкретно — к строке, в которой абонент попадает в очередь:

1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453ХХХХ|1

При возникновении события «ENTERQUEUE» один из параметров — необходимый нам номер абонента. Нам остается только отыскать данную строку в файле queue_log. Этим как раз занимается скрипт на bash, который MONIT нам заботливо вызвал:

#!/bin/bash
#MONIT_DESCRITION - строка, которая передана как параметр в скрипт.
#Преобразуем timestamp в человеческое представление даты-времени (параметр №1).
timedate=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2 | gawk '{print strftime("%d.%m.%Y %H:%M:%S",$0);}')
#Получаем UID (параметр №2)
call_id=$(echo $MONIT_DESCRIPTION | cut -d\| -f2)
#и номер очереди (параметр №3)
qnum=$(echo $MONIT_DESCRIPTION | cut -d\| -f3)

#По номеру очереди присваиваем ей человеческое имя
case $qnum in
    210)
        qname="Очередь 1"
        ;;
    220)
        qname="Очередь 2"
        ;;
esac

#И ищем в логе строку с UID, номером очереди и событием ENTERQUEUE
str=$(grep "|$call_id|$qnum|.*|ENTERQUEUE" /var/log/asterisk/queue_log)
#Получаем из неё номер позвонившего абонента (параметр №7)
caller_id=$(echo $str | cut -d\| -f7)
#Время его попадания в очередь (паоаметр №1)
time_enter=$(echo $str | cut -d\| -f1)
#И время пропадания из очедери (параметр №1 из события ABANDON)
time_abandon=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2)
#Формируем сообщение
data="Абонент $caller_id $timedate позвонил в $qname, не дождался ответа и отбился через $(($time_abandon-$time_enter)) сек."
#И отправляем его в мессенджер/почту. В данном случае это Slack.
/usr/bin/curl -X POST -H 'Content-type: application/json' --data '{"text":"'"$data"'"}' "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

Собственно, и всё!

Правда, есть один казус — MONIT, предназначенный для мониторинга всего и вся, сам нуждается в мониторинге, т.к. периодически падает.

Теги:

Хабы:

Asterisk

Asterisk и отправка пропущенных в Telegram/Slack/E-mail

Публикации

Истории

Ближайшие события