Il y a un centre d'appels. Il y a Asterisk / FreePBX avec des files d'attente configurées. Il y a des agents qui devraient répondre aux appels. Mais il y a tellement de clients potentiels, et il y a si peu d'agents que le premier ne peut en aucun cas atteindre le second - il se bloque en ligne pendant une minute, et il s'éteint.Mais pour une raison quelconque, ils ont appelé! Peut-être veulent-ils apporter de l'argent à l'entreprise? Essayons de retourner les clients et leur argent en utilisant l'exemple FreePBX.Dans les paramètres de la file d'attente, vous pouvez spécifier la destination de basculement - où envoyer l'appel lorsque la file d'attente est pleine, le délai d'expiration s'est écoulé, etc. Mais il arrive souvent que l'appelant se déconnecte avant d'être redirigé vers la destination de basculement - vous ne savez jamais, la connexion est déconnectée. Il n'y a pas de solution toute faite pour de tels cas. Par conséquent, nous allons sous la coupe et écrivons les nôtres - en envoyant une alerte à Telegram / Slack / E-mail / ailleurs.Et la première chose que nous devons comprendre, c'est comment FreePBX écrit les journaux de file d'attente. Dans le cas le plus simple, il s'agit du fichier texte / var / log / asterisk / queue_log.Ainsi, un appel régulier est écrit dans le journal de l'abonné 8964467XXXXX, qui a appelé 302221XXXX, qui est en ligne n ° 603 à la première position, à laquelle l'agent Girl a répondu 8 secondes plus tard. Ils ont parlé 133 secondes et l'abonné a été le premier à raccrocher - tout le monde aurait des gestionnaires aussi polis!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
Et voici une histoire légèrement différente lorsqu'un abonné 8996453XXXXX a téléphoné au 302257XXXXX, suspendu 10 secondes dans la ligne n ° 210 en première position et déconnecté. Je n'ai même pas écouté le menu vocal!1581728710|1581728690.59367|210|NONE|DID|302257
1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
C'est à propos de lui, nous écrirons dans le messager.Pour ce faire, nous devons intercepter l'occurrence de l'événement ABANDON dans le fichier journal. J'ai longtemps été perplexe sur la façon dont cela peut être fait, mais par hasard, je suis tombé sur un merveilleux outil - MONIT . Dans notre cas, il surveillera le journal de file d'attente, et dès que la ligne «ABANDON» y apparaîtra, il appellera le script pour traiter cet événement.Pour ce faire, après avoir installé le package:yum install monit
Configurez-le - créez le fichier /etc/monit.d/queue_log et écrivez littéralement trois lignes dedans:check file queue_log with path /var/log/asterisk/queue_log
if content = "ABANDON" then
exec "/var/lib/asterisk/agi-bin/qlogevent.sh $EVENT"
Ainsi, lorsque le mot "ABANDON" apparaît dans le journal de file d'attente, ce qui nous dit de déconnecter prématurément l'abonné, le script /var/lib/asterisk/agi-bin/qlogevent.sh avec le paramètre $ EVENT sera appelé, ce qui n'est rien d'autre que complètement la ligne dans laquelle ce mot est apparu.C'est simple.Et maintenant ce ne sont pas les échecs qui commencent - vous devez y penser.La ligne passée au script ne contient pas d'informations sur le numéro de l'appelant:1581728720|1581728690.59367|210|NONE|ABANDON|1|1|10
Il n'a que l'horodatage (1581728720), un ID d'appel unique (1581728690.59367), un numéro de file d'attente (210), l'événement lui-même et quelques autres paramètres non essentiels. Ceux. Nous devrons rechercher le numéro d'abonné nous-mêmes. Et de quelle manière? Et c’est très simple, car nous avons l’UID d’un appel!Revenons à nouveau au journal de cet appel, en particulier à la ligne dans laquelle l'abonné tombe dans la file d'attente:1581728710|1581728690.59367|210|NONE|ENTERQUEUE||8996453|1
Lorsque l'événement "ENTERQUEUE" se produit, l'un des paramètres est le numéro d'abonné dont nous avons besoin. Nous ne pouvons trouver cette ligne que dans le fichier queue_log. C'est exactement ce que fait le script bash, que MONIT a soigneusement appelé pour nous:#!/bin/bash
timedate=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2 | gawk '{print strftime("%d.%m.%Y %H:%M:%S",$0);}')
call_id=$(echo $MONIT_DESCRIPTION | cut -d\| -f2)
qnum=$(echo $MONIT_DESCRIPTION | cut -d\| -f3)
case $qnum in
210)
qname=" 1"
;;
220)
qname=" 2"
;;
esac
str=$(grep "|$call_id|$qnum|.*|ENTERQUEUE" /var/log/asterisk/queue_log)
caller_id=$(echo $str | cut -d\| -f7)
time_enter=$(echo $str | cut -d\| -f1)
time_abandon=$(echo $MONIT_DESCRIPTION | cut -d\| -f1 | cut -d\: -f2)
data=" $caller_id $timedate $qname, $(($time_abandon-$time_enter)) ."
/usr/bin/curl -X POST -H 'Content-type: application/json' --data '{"text":"'"$data"'"}' "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
En fait, c'est tout!Certes, il y a un incident - MONIT, conçu pour tout surveiller et tout; il a lui-même besoin d'être surveillé, car tombe périodiquement.